B.A.T.M.A.N November 2007

b.a.t.m.a.n@lists.open-mesh.org

13 participants
22 discussions

[B.A.T.M.A.N.] two-way-tunnel quirks
by Jan Hetges 06 Dec '07

06 Dec '07

Hi all as i'm running bmxd-rv804 only ;-) for almost two weeks now, almost without problems... now i found an issue which i didn't relate with batman first. I got several reports of users, hotmail/msn/live.com not being accessible anymore... Yesterday i found out theres also problems with some pop server not beeing accessible, but everything works fine directly at the upstream gw, without any batmand involved. reenableing the old one-way-tunnel solved all the problems. cheers --Jan

4 13

[B.A.T.M.A.N.] gateway-tunnel crashes with multiple net-dev
by tetzlav 29 Nov '07

29 Nov '07

Its me again... ;) At first i thought this is a problem with our complex setup on the freifunk-routers with olsr+batman on alias-interfaces and so on, but know i testet batman on my Laptop and have the same problems with multiple network interfaces and gateway-tunnels. I dont know how this gateway-tunnels really works, but i think this pseudo-NAT on gate0 not really works or send wrong source-IP or what else... Regards tetzlav -----<tunnel-client>----- root@tetzlav # ./batmand -v B.A.T.M.A.N. 0.3-beta rv799 (compatibility version 4) root@tetzlav # ip addr | sed 's/$..:..$:..:..:/\1:XX:XX:/' 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue link/loopback 00:00:XX:XX:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 170: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:09:XX:XX:cb:9d brd ff:ff:ff:ff:ff:ff inet 192.168.105.254/24 brd 192.168.105.255 scope global eth0 inet6 fe80::209:6bff:fe3f:cb9d/64 scope link valid_lft forever preferred_lft forever 171: eth2: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:01:XX:XX:c3:8f brd ff:ff:ff:ff:ff:ff inet 192.168.1.2/24 brd 192.168.1.255 scope global eth2 inet6 fe80::201:3ff:fe81:c38f/64 scope link valid_lft forever preferred_lft forever 174: wifi0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 199 link/ieee802.11 00:90:XX:XX:07:e1 brd ff:ff:ff:ff:ff:ff 175: ath0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue link/ether 06:90:XX:XX:07:e1 brd ff:ff:ff:ff:ff:ff inet 105.61.17.106/8 brd 105.255.255.255 scope global ath0 inet6 fe80::490:4bff:fedc:7e1/64 scope link valid_lft forever preferred_lft forever root@tetzlav # ./batmand -r2 ath0 && ./batmand -cd3 Using interface ath0 with address 105.61.17.106 and broadcast address 105.255.255.255 Adding route to 105.61.17.35 via 0.0.0.0 (table 66 - ath0) Adding route to 105.61.89.89/32 via 105.61.17.35 (table 65 - ath0) Found new gateway 105.61.17.35 -> class: 65 - 16MBit/4MBit Adding route to 105.61.17.17/32 via 105.61.17.35 (table 66 - ath0) Adding route to 105.61.13.18/32 via 105.61.17.35 (table 66 - ath0) Adding route to 105.61.89.81/32 via 105.61.17.35 (table 65 - ath0) Adding route to 105.61.17.21/32 via 105.61.17.35 (table 66 - ath0) Adding route to 105.61.89.90/32 via 105.61.17.35 (table 65 - ath0) Adding route to 105.61.17.32/32 via 105.61.17.35 (table 66 - ath0) Adding route to 105.61.17.18 via 0.0.0.0 (table 66 - ath0) Deleting route to 105.61.17.18 via 0.0.0.0 (table 66 - ath0) Adding route to 105.61.17.18/32 via 105.61.17.35 (table 66 - ath0) Adding route to 105.61.17.1/32 via 105.61.17.35 (table 66 - ath0) Adding route to 105.61.89.92/32 via 105.61.17.35 (table 65 - ath0) Adding route to 105.61.18.12/32 via 105.61.17.35 (table 66 - ath0) Adding route to 105.61.17.19/32 via 105.61.17.35 (table 66 - ath0) Found new gateway 105.61.17.19 -> class: 41 - 2048KBit/512KBit Adding default route to 105.61.17.35 (gw_flags: 65, tq: 240, gw_product: 0) Gateway client - got IP (169.254.0.1) from gateway: 105.61.17.35 Adding default route via gate0 (table 68) Gateway client - gateway (105.61.17.35) says: IP (169.254.0.1) is expired Deleting default route via gate0 (table 68) Adding default route to 105.61.17.35 (gw_flags: 65, tq: 240, gw_product: 0) Gateway client - got IP (169.254.0.1) from gateway: 105.61.17.35 Adding default route via gate0 (table 68) Gateway client - gateway (105.61.17.35) says: IP (169.254.0.1) is expired Deleting default route via gate0 (table 68) Adding default route to 105.61.17.35 (gw_flags: 65, tq: 240, gw_product: 0) Gateway client - got IP (169.254.0.1) from gateway: 105.61.17.35 Adding default route via gate0 (table 68) Gateway client - gateway (105.61.17.35) says: IP (169.254.0.1) is expired Deleting default route via gate0 (table 68) root@tetzlav # while sleep 1; do tcpdump -vvvni gate0; done 16:07:13.079874 IP (tos 0x0, ttl 7, id 7998, offset 0, flags [none], proto: ICMP (1), length: 64) 169.254.0.1 > 141.1.1.1: ICMP echo request, id 56067, seq 32519, length 44 16:07:13.109311 IP (tos 0x0, ttl 248, id 0, offset 0, flags [none], proto: ICMP (1), length: 56) 195.2.10.37 > 169.254.0.1: ICMP time exceeded in-transit, length 36 IP (tos 0x0, ttl 1, id 7998, offset 0, flags [none], proto: ICMP (1), length: 64) 169.254.0.1 > 141.1.1.1: ICMP echo request, id 56067, seq 32519, length 44 16:07:13.207659 IP (tos 0x0, ttl 8, id 7999, offset 0, flags [none], proto: ICMP (1), length: 64) 169.254.0.1 > 141.1.1.1: ICMP echo request, id 56067, seq 32775, length 44 16:07:13.236168 IP (tos 0x0, ttl 57, id 56889, offset 0, flags [none], proto: ICMP (1), length: 64) 141.1.1.1 > 169.254.0.1: ICMP echo reply, id 56067, seq 32775, length 44 16:07:13.336254 IP (tos 0x0, ttl 1, id 8000, offset 0, flags [none], proto: ICMP (1), length: 64) 169.254.0.1 > 141.1.1.1: ICMP echo request, id 56067, seq 33031, length 44 16:07:13.337616 IP (tos 0xc0, ttl 64, id 56062, offset 0, flags [none], proto: ICMP (1), length: 92) 169.254.0.0 > 169.254.0.1: ICMP time exceeded in-transit, length 72 IP (tos 0x0, ttl 1, id 8000, offset 0, flags [none], proto: ICMP (1), length: 64) 169.254.0.1 > 141.1.1.1: ICMP echo request, id 56067, seq 33031, length 44 16:07:13.360347 IP (tos 0x0, ttl 64, id 10973, offset 0, flags [DF], proto: TCP (6), length: 64) 192.168.105.254.47000 > 217.10.10.194.5223: ., cksum 0xe918 (correct), 3496148623:3496148635(12) ack 3669129091 win 2003 <nop,nop,timestamp 230212021 497584259> tcpdump: pcap_loop: recvfrom: Network is down 29 packets captured 29 packets received by filter 0 packets dropped by kernel tcpdump: SIOCGIFHWADDR: No such device tcpdump: SIOCGIFHWADDR: No such device -----<on batman-gateway>---- root@17-35:~# batmand -cd3 Deleting route to 105.61.18.12/32 via 105.61.89.92 (table 66 - vlan1:bat) Adding route to 105.61.18.12/32 via 105.61.89.81 (table 66 - vlan1:bat) Deleting route to 105.61.18.12/32 via 105.61.89.81 (table 66 - vlan1:bat) Adding route to 105.61.18.12/32 via 105.61.89.92 (table 66 - vlan1:bat) Gateway - assigned 169.254.0.1 to client: 105.61.17.106 Deleting route to 105.61.17.18 via 0.0.0.0 (table 66 - eth2:bat) Adding route to 105.61.17.18/32 via 105.61.89.81 (table 66 - vlan1:bat) Gateway - assigned 169.254.0.1 to client: 105.61.17.106 Deleting route to 105.61.17.18/32 via 105.61.89.81 (table 66 - vlan1:bat) Adding route to 105.61.17.18 via 0.0.0.0 (table 66 - eth2:bat) Gateway - assigned 169.254.0.1 to client: 105.61.17.106 Gateway - assigned 169.254.0.1 to client: 105.61.17.106 Gateway - assigned 169.254.0.1 to client: 105.61.17.106 Gateway - assigned 169.254.0.1 to client: 105.61.17.106 Deleting route to 105.61.18.12/32 via 105.61.89.92 (table 66 - vlan1:bat) Adding route to 105.61.18.12/32 via 105.61.89.81 (table 66 - vlan1:bat) Gateway - assigned 169.254.0.1 to client: 105.61.17.106 Deleting route to 105.61.18.12/32 via 105.61.89.81 (table 66 - vlan1:bat) Adding route to 105.61.18.12/32 via 105.61.89.92 (table 66 - vlan1:bat) Gateway - assigned 169.254.0.1 to client: 105.61.17.106 Gateway - assigned 169.254.0.1 to client: 105.61.17.106 Gateway - assigned 169.254.0.1 to client: 105.61.17.106 root@17-35:~# logread -f Nov 17 16:24:16 (none) daemon.err batmand[12811]: Error - got packet from unknown client: 105.61.17.106 (virtual ip 192.168.105.254) Nov 17 16:24:21 (none) daemon.err batmand[12811]: Error - got packet from unknown client: 105.61.17.106 (virtual ip 192.168.105.254) Nov 17 16:24:32 (none) daemon.err batmand[12811]: Error - got packet from unknown client: 105.61.17.106 (virtual ip 192.168.105.254) Nov 17 16:24:34 (none) daemon.err batmand[12811]: Error - got packet from unknown client: 105.61.17.106 (virtual ip 192.168.105.254) Nov 17 16:24:38 (none) daemon.err batmand[12811]: Error - got packet from unknown client: 105.61.17.106 (virtual ip 192.168.105.254) Nov 17 16:24:51 (none) daemon.err batmand[12811]: Error - got packet from unknown client: 105.61.17.106 (virtual ip 192.168.105.254) Nov 17 16:24:56 (none) daemon.err batmand[12811]: Error - got packet from unknown client: 105.61.17.106 (virtual ip 192.168.105.254) Nov 17 16:25:02 (none) daemon.err batmand[12811]: Error - got packet from unknown client: 105.61.17.106 (virtual ip 192.168.105.254) Nov 17 16:25:04 (none) daemon.err batmand[12811]: Error - got packet from unknown client: 105.61.17.106 (virtual ip 192.168.105.254)

3 5

[B.A.T.M.A.N.] batmand still doesn't start the right way
by rene 25 Nov '07

25 Nov '07

Hi all, still having problem with batman. Mostly it starts without any problems, but sometimes it seems not to do what it should. In the following example, for instance, batmand sends OG-messages only through ath0:1 (192.168.41.186) and ath1:1 (192.168.42.186), but not through eth0:1 (which is the only interface where another batman-node, 192.168.40.184 is connected, OGs from this node are received). Any Ideas? Regards, Rene -------------------------------------------------------------------- root@OpenWrt:~# /etc/init.d/batmand start Starting batmand... Using interface eth0:1 with address 192.168.40.186 and broadcast address 192.168.43.255 Using interface ath0:1 with address 192.168.41.186 and broadcast address 192.168.43.255 Using interface ath1:1 with address 192.168.42.186 and broadcast address 192.168.43.255 root@OpenWrt:~# tcpdump -i ath1:1 port 4305 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ath1:1, link-type EN10MB (Ethernet), capture size 96 bytes 05:51:36.614733 IP 192.168.42.186.4305 > 192.168.43.255.4305: UDP, length 25 05:51:36.832907 IP 192.168.42.186.4305 > 192.168.43.255.4305: UDP, length 15 05:51:37.224704 IP 192.168.42.186.4305 > 192.168.43.255.4305: UDP, length 25 05:51:37.683458 IP 192.168.42.186.4305 > 192.168.43.255.4305: UDP, length 25 05:51:37.843369 IP 192.168.42.186.4305 > 192.168.43.255.4305: UDP, length 15 5 packets captured 10 packets received by filter 0 packets dropped by kernel root@OpenWrt:~# tcpdump -i ath0:1 port 4305 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ath0:1, link-type EN10MB (Ethernet), capture size 96 bytes 05:51:44.454408 IP 192.168.41.186.4305 > 192.168.43.255.4305: UDP, length 25 05:51:44.702985 IP 192.168.41.186.4305 > 192.168.43.255.4305: UDP, length 15 05:51:44.732650 IP 192.168.41.186.4305 > 192.168.43.255.4305: UDP, length 25 05:51:45.492874 IP 192.168.41.186.4305 > 192.168.43.255.4305: UDP, length 25 05:51:45.682386 IP 192.168.41.186.4305 > 192.168.43.255.4305: UDP, length 15 05:51:45.693262 IP 192.168.41.186.4305 > 192.168.43.255.4305: UDP, length 25 05:51:46.582916 IP 192.168.41.186.4305 > 192.168.43.255.4305: UDP, length 25 05:51:46.622357 IP 192.168.41.186.4305 > 192.168.43.255.4305: UDP, length 15 05:51:46.712604 IP 192.168.41.186.4305 > 192.168.43.255.4305: UDP, length 25 9 packets captured 18 packets received by filter 0 packets dropped by kernel root@OpenWrt:~# tcpdump -i eth0:1 port 4305 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0:1, link-type EN10MB (Ethernet), capture size 96 bytes 05:51:52.051159 IP 192.168.40.184.4305 > 192.168.43.255.4305: UDP, length 25 05:51:52.543207 IP 192.168.40.184.4305 > 192.168.43.255.4305: UDP, length 25 05:51:53.130721 IP 192.168.40.184.4305 > 192.168.43.255.4305: UDP, length 25 05:51:53.622574 IP 192.168.40.184.4305 > 192.168.43.255.4305: UDP, length 25 05:51:54.200698 IP 192.168.40.184.4305 > 192.168.43.255.4305: UDP, length 25 05:51:54.661832 IP 192.168.40.184.4305 > 192.168.43.255.4305: UDP, length 25 05:51:55.180689 IP 192.168.40.184.4305 > 192.168.43.255.4305: UDP, length 25 05:51:55.581781 IP 192.168.40.184.4305 > 192.168.43.255.4305: UDP, length 25 05:51:56.150711 IP 192.168.40.184.4305 > 192.168.43.255.4305: UDP, length 25 9 packets captured 18 packets received by filter 0 packets dropped by kernel root@OpenWrt:~#

5 13

[B.A.T.M.A.N.] routing problem?
by Stefano Scipioni 24 Nov '07

24 Nov '07

I'm testing batman 0.3 exp rv 777 traceroute give me a problem root@sala:~$ traceroute 10.0.1.1 traceroute: can't find interface root@sala:~$ ip route ls tab 66 10.1.5.104 dev ath0 proto static scope link src 10.1.5.102 10.1.5.130 via 10.1.5.104 dev ath0 proto static 10.1.5.129 via 10.1.5.1 dev ath0 proto static 10.1.5.1 via 10.1.5.104 dev ath0 proto static root@sala:~$ ip route ls tab 65 10.0.1.0/24 via 10.1.5.1 dev ath0 proto static root@sala:~$ traceroute 10.0.1.1 traceroute: can't find interface root@sala:~$ ping 10.0.1.1 PING 10.0.1.1 (10.0.1.1): 56 data bytes 64 bytes from 10.0.1.1: seq=0 ttl=61 time=9.119 ms 64 bytes from 10.0.1.1: seq=1 ttl=61 time=8.486 ms traceroute works If I utilize source address option. What is my mistake? Also if one of nodes has no batman-exp running on it I can't reach it from neighbours (I use batmand on ath0 interface, not an alias)? Perhaps I have to use --no-unreachable-rule? Stefano

5 12

AW: [B.A.T.M.A.N.] wrong ip rules
by Marek Lindner 21 Nov '07

21 Nov '07

Hi, > 6598: from all to 104.0.0.0/8 lookup olsr > 6599: from 104.0.0.0/8 lookup olsr > 6598: from all to 104.0.0.0/8 lookup olsr > 6599: from 104.0.0.0/8 lookup olsr > 6802: from 104.0.0.0/8 lookup 68 > batmand delete olsr-rules and set "from 104.0.0.0/8 lookup 68"!? which olsr-rules are deleted ? I can't see a difference there. In table 68 is the batman default route. All interfaces not controlled by batmand are routed towards this routing table. If you don't want that OLSR traffic is routed into the batman default route you have 2 choices: - You deleted the OLSR rules after each batmand start (hackish). - You use the --no-policy-routing option and set all rules by yourself. This option allows a tight integration into a firmware and full control of the policy routing. Why does batmand not recognize OLSR interfaces and ignores them ? We simply could not find a good solution for this kind of detection but we are open to suggestions. ;-) Greetings, Marek __________________________________ Ihr erstes Fernweh? Wo gibt es den schönsten Strand? www.yahoo.de/clever

5 6

[B.A.T.M.A.N.] problem starting batmand (v799)
by Sebastian Hagen 20 Nov '07

20 Nov '07

Hello *, I'm the author of the mipip olsrd patch mentioned by rene. The olsrd code was very close to doing the Right Thing (see below), my patch just fixed a few minor internal API issues that prevented it from working out correctly. I haven't seriously looked at the b.a.t.m.a.n. code, so I don't know exactly why it's causing problems for rene. Axel Neumann wrote: > IMO that does only work if the interfaces of a node are NOT connected to the > same physical/logical link (e.g. B1 and B2 are operating on different > channels or with different cell IDs,...). Otherwise specifying the outgoing > interface is not enough. Even if node A has only one interface (A1). If there > is a link A1<->B1 and a link A1<->B2 the problem remains: >> > How could it set up the routing table to ensure that a packet >> > to a distant node C should be routed via B1 (and NOT via B2)? > The outgoing interface of node A is A1, for both cases. Setting the outgoing > interface to A1 has no effect. > > Maybe there is a way to configure the next-hop-mac address instead of the > next-hop-ip address. But then you rather have layer 2 routing and not layer > 3. This is an interesting case. You're correct that in this configuration, a l3 routing daemon on A can't make a deliberate choice of which interface of B to send data to. This is obviously suboptimal, and should be avoided. However, there are plenty of cases where this will predictably not occur. For instance, in the opennet mesh network in Rostock, we have quite a lot of nodes which have one wired interface and one wireless interface, both of which are used for communication with other nodes in the mesh cloud. Assigning separate IP addresses to the different interfaces on those nodes would be wasteful of our address space. Imo, the choice whether to assign different IP addresses to the different interfaces on a specific meshnode should ideally lie with the (hopefully competent) network admins, and routing daemons should decently support either configuration, with the implicit understanding that having different interfaces a) in the same broadcast domain AND b) with the same IP addresses may lead to silent performance degradation. That's what the newer versions of olsrd do. Regards, Sebastian Hagen

1 0

[B.A.T.M.A.N.] problem starting batmand (v799)
by rene 20 Nov '07

20 Nov '07

Hi, starting batmand, the daemon sometimes doesn't seem to recognize the network the right way. root@25:~# killall batmand root@25:~# batmand eth1:1 vlan0:1 Using interface eth1:1 with address 192.168.42.25 and broadcast address 192.168.43.255 Using interface vlan0:1 with address 192.168.42.25 and broadcast address 192.168.43.255 ------------------------------------------------------- This is a tcpdump from a neighbor node: root@ap14:~# tcpdump -i eth0 src 192.168.42.25 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 05:12:09.512310 arp who-has 192.168.43.255 tell 192.168.42.25 05:12:10.512178 arp who-has 192.168.43.255 tell 192.168.42.25 05:12:11.699795 arp who-has 192.168.43.255 tell 192.168.42.25 ------------------------------------------- on the other node: root@25:~# killall batmand root@25:~# batmand eth1:1 vlan0:1 Using interface eth1:1 with address 192.168.42.25 and broadcast address 192.168.43.255 Using interface vlan0:1 with address 192.168.42.25 and broadcast address 192.168.43.255 root@25:~# ---------------------------------------------- tcpdump: 05:12:28.621940 IP 192.168.42.25.4305 > 192.168.43.255.4305: UDP, length 20 05:12:28.873246 IP 192.168.42.25.4305 > 192.168.43.255.4305: UDP, length 25 05:12:28.892343 IP 192.168.42.25.4305 > 192.168.43.255.4305: UDP, length 15 now batmand is running successfully. Any Ideas? regards, Rene

3 10

[B.A.T.M.A.N.] adding network announce
by Jan Hetges 18 Nov '07

18 Nov '07

Hi is that supposed to work? at least, first it says it does, but second it doesn't: root@bla:~# bmxd -c -a 172.16.x.x/32 WARNING: You are using BatMan-eXp 0.3-alpha rv802 (compatibility version 9) ! adding HNA 172.16.x.x/32, atype 1 bmxd -r 3 -a 172.17.x.x/24 eth1:bmx (172.17.x.x/24 is the network already announced at startup) cheers --Jan

2 1

[B.A.T.M.A.N.] parametrization for bmxd on ethernet?
by Jan Hetges 16 Nov '07

16 Nov '07

Hi I did'nt find doku on that. As i'm getting a 2nd GW :-)... setup: ---"DMZ" / vsat --- gateway ------ wifi-gw --- "wifi-world" --- 2nd-wifi-gw \ ---"wifi-world-2" I'm running bmxd-rv785 on all the wireless stuff, where wifi-gw runs bmxd -g -blabla, but i liked to move the bmxd-gw to the cabled gw, so if the sat-link fails, "wifi-world-2" and "DMZ" can still reach the internet through the 2nd-wifi-gw. So howto parametrize bmxd for devices without wireless-intrerface? Can i use --gateway-change-hysteresis together with -p ? Suggestion: in bmxd -cbd1 i saw nodes with lvld >400 before they get deleted, i think 180 should be more than enough, 3 minutes is plenty of time for normal reboot, and if a node dosn't send OGMs for more than that... it has a serious problem ;) cheers --Jan

2 4

[B.A.T.M.A.N.] WICHTIG/IMPORTANT - freifunk-batman: Sicherheitslücke/security problem
by Lui 16 Nov '07

16 Nov '07

[english below] Hallo! die beiden bislang aktuellen freifunk-batman Pakete (0.83.1 und 0.84beta02) haben leider eine derart fette *Sicherheitslücke* (Dank an Jo-Philipp Wich [Leipzig] für den Hinweis!), daß eine UMGEHENDE Aktualisierung DRINGEND angeraten ist! Die gefixte Version (auf Basis von "0.84") findet sich als: http://freifunk.schmudde.com/ipkg/freifunk-batman_0.2-0.84.10.ipkg (Hinweis: weiterhin /nur/ batmand *0.2* - daher der Versions#-"zusatz") Hintergründe - gibt's dann später... Bitte informiert auch Leute, die es auf diesem Weg u.U. nicht erreicht... Danke & sorry Lui --- Hello! the freifunk-batman packages up to version 0.84beta02 have a huge security problem (thanks to Jo-Philipp Wich [Leipzig] for the note). So, an IMMEDIATE update is highly recommended! Find the fixed Version (based on "0.84"), as: http://freifunk.schmudde.com/ipkg/freifunk-batman_0.2-0.84.10.ipkg (Note: This is still a batmand *0.2-only* packet - now indicated by the version-string) Backgrounds: after a while... Please forward this information to people who may not get it this way. Thanks & sorry Lui

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N November 2007