Hi, since you use mipsel device I think these mips log could be of more help in fixing mips/mipsel bug in 0.3 branches (alpha and experimental).
Very simple scenario: [client 5.1.7.251]----mesh----[gateway 5.1.7.254] all node running 0.3 apha (the today latest rv6300.3-alpha)
##### d3 level debug at client ... 1) Adding throw route to 169.254.0.0/16 via 0.0.0.0 (table 68 - eth0:1) 2) Adding throw route to 127.0.0.0/8 via 0.0.0.0 (table 68 - lo) 3) Adding throw route to 10.7.251.128/25 via 0.0.0.0 (table 68 - ath2) 4) Adding throw route to 5.0.0.0/8 via 0.0.0.0 (table 68 - ath0) 5) Adding throw route to 10.7.251.0/25 via 0.0.0.0 (table 68 - br0) 6) Adding route to 5.1.7.254 via 0.0.0.0 (table 66 - ath0) 7) Found new gateway 5.1.7.254 -> class: 49 - 4MBit/1024KBit
# after sliding windows if filled in by validate OGMs
8) Adding default route to 5.1.7.254 (gw_flags: 49, packet_count: 64, gw_product: 0) 9) Adding default route via tun0 (table 68)
# ...ah this is great! now trying to ping outside mesh
10) Gateway client - got IP (1.0.254.169) from gateway: 5.1.7.254 11) Gateway client - gateway (5.1.7.254) says: IP (1.0.254.169) is expired
# client can't exit off mesh
##### d3 level debug at gateway ... 1) gateway class: 49 -> propagating: 4MBit/1024KBit 2) Error - can't add route to 0.0.254.169/24 via 0.0.0.0 (table 254): Invalid argument
# (don't know why previous error) # ...gateway is learned about client wants ping outside mesh
3) Gateway - assigned 1.0.254.169 to client 5.1.7.251 4) Error - got packet from unknown client: 5.1.7.251 (virtual ip 1.0.254.169)
What I see:
FIRST BUG (?) Client prepare route to 169.254.0.0/16 in table 68 (line 1-log_client) while gateway arrange a 169.254.0.0/24 space (line 2-log_gateway): suffix bits differs (16 bit netmask client side vs 24 bit netmask server side)
SECOND BUG Client wants ping outside mesh and receives a *little endian formatted* IP 1.0.254.169 (line 10-log_client and line 3-log_gateway) which is out of previous arrangement (this IP address is malformed by gateway).
Client tryes sending outgoing packet to gateway
Gateway receives client' outgoing packect but doesn't recognize IP source address (line 4-log_gateway) expecting one in 0.0.254.169/24 space. Thus gateway informs client about wrong IP, so client pinging fails (line 11-log_client).
Hopeing this will be usefull... I know today weekend begins :)
-- Antonio
Hi,
since you use mipsel device I think these mips log could be of more help in fixing mips/mipsel bug in 0.3 branches (alpha and experimental).
Hopeing this will be usefull... I know today weekend begins :)
thanks a lot for your thorough description - it did help. :-) Since the weekend is shorter than one might think I already issued a patch. It should work now but due to the lack of Big Endian CPUs I can't test it. I would be happy if you checked on that. After you confirmed the end of this bug I will fix the experimental branch as well.
Regards, Marek
great work Marek, now client can ping outside mesh obtaining the correct IP from gateway. Thanks!
Still remain the minor problem in arrangement of IPIPA subnet mask: 169.254.0.0/16 on clients 169.254.0.0/24 on gateway
Have a fine weekend
-- Antonio
space (line 2-log_gateway): suffix
Hi,
since you use mipsel device I think these mips log could be of more help in fixing mips/mipsel bug in 0.3 branches (alpha and experimental).
Hopeing this will be usefull... I know today weekend begins :)
thanks a lot for your thorough description - it did help. :-) Since the weekend is shorter than one might think I already issued a patch. It should work now but due to the lack of Big Endian CPUs I can't test it. I would be happy if you checked on that. After you confirmed the end of this bug I will fix the experimental branch as well.
Regards, Marek _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Am Samstag, 22. September 2007 20:00:04 schrieb a.anselmi@oltrelinux.com:
great work Marek, now client can ping outside mesh obtaining the correct IP from gateway. Thanks!
Goooood. This makes the weekend even better. ;-)
Still remain the minor problem in arrangement of IPIPA subnet mask: 169.254.0.0/16 on clients 169.254.0.0/24 on gateway
I don't know where you can see that. The tun interface is a point to point connection ...
Greetings, Marek
PS: 2 hours reponse time isn't that bad, is it ? :)
Still remain the minor problem in arrangement of IPIPA subnet mask: 169.254.0.0/16 on clients 169.254.0.0/24 on gateway
I don't know where you can see that. The tun interface is a point to > > point connection ...
...sure, it was a safe-IP on my router which cause that messages about 169.254.0.0 route: now changed safe-IP out of ipipa subnet.
PS: 2 hours reponse time isn't that bad, is it ? :)
...that's the way! (K.C. & Sunshine Band, early 70's)
ciao
-- Antonio
Am Samstag, 22. September 2007 21:41:21 schrieb a.anselmi@oltrelinux.com:
Still remain the minor problem in arrangement of IPIPA subnet mask: 169.254.0.0/16 on clients 169.254.0.0/24 on gateway
I don't know where you can see that. The tun interface is a point to > > point connection ...
...sure, it was a safe-IP on my router which cause that messages about 169.254.0.0 route: now changed safe-IP out of ipipa subnet.
Excuse my ignorance but what is "ipipa" ? Even wikipedia does not know it. ;-) And let me repeat my question: Where did you see that routing entry "169.254.0.0/16" ? Or is that problem also gone ?
Greetings, Marek
he means Apipa... http://compnetworking.about.com/cs/protocolsdhcp/g/bldef_apipa.htm as soon as something starts with 169.x.y.z I guess.. netmask 255.0.0.0
2007/9/22, Marek Lindner lindner_marek@yahoo.de:
Am Samstag, 22. September 2007 21:41:21 schrieb a.anselmi@oltrelinux.com:
Still remain the minor problem in arrangement of IPIPA subnet mask: 169.254.0.0/16 on clients 169.254.0.0/24 on gateway
I don't know where you can see that. The tun interface is a point to >
point connection ...
...sure, it was a safe-IP on my router which cause that messages about 169.254.0.0 route: now changed safe-IP out of ipipa subnet.
Excuse my ignorance but what is "ipipa" ? Even wikipedia does not know it. ;-) And let me repeat my question: Where did you see that routing entry "169.254.0.0/16" ? Or is that problem also gone ?
Greetings, Marek _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
169.254.0.0/16 is the MDNS (multicast DNS) address space. Part of zeroconf repectively 'Bonjour' (Apple Computers)
This has nothing to do with Batman.
cu elektra
Hi, ipipa was a my typo... I was meaning apipa.
"Windows 98, 98 SE, Me, and 2000 have an Automatic Private IP Addressing (APIPA) feature that will automatically assign an Internet Protocol address to a computer on which it installed. This occurs when the TCP/IP protocol is installed, set to obtain it's IP address automatically from a Dynamic Host Configuration Protocol server, and when there is no DHCP server present or the DHCP server is not available. The Internet Assigned Numbers Authority (IANA) has reserved private IP addresses in the range of 169.254.0.0 -169.254.255.255 for Automatic Private IP Addressing."
good weekend to all batman team
Antonio
169.254.0.0/16 is the MDNS (multicast DNS) address space. Part of zeroconf repectively 'Bonjour' (Apple Computers)
This has nothing to do with Batman.
cu elektra _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Marek,
I hate to bother you but you were so responsive before...
Antonio just put up a post. We are both seeing the same problem - computers associated with repeaters on 0.3 (MIPS) can't browse. But ssh into that node and do a wget and it works great!. If we just replace 0.3 with 0.2 all works again.
Also, I am tracking memory and see it dropping steadily on the nodes (500k in about 12 hours). This didn't happen with 0.2 and that is all that has changed.
Is there any way you can look into this ASAP? We are very close to having to give code to our supplier for the routers and we would very much like to ship with 0.3 rather than 0.2.
Thank you for your help!
FYI, we sent you 6 merakis today. I'll get you a tracking number shortly.
Mike
-----Original Message----- From: b.a.t.m.a.n-bounces@open-mesh.net [mailto:b.a.t.m.a.n-bounces@open-mesh.net] On Behalf Of Marek Lindner Sent: Saturday, September 22, 2007 11:52 AM To: The list for a Better Approach To Mobile Ad-hoc Networking Subject: Re: [B.A.T.M.A.N.] 0.3 alpha (today revison)
Am Samstag, 22. September 2007 20:00:04 schrieb a.anselmi@oltrelinux.com:
great work Marek, now client can ping outside mesh obtaining the correct IP from
gateway.
Thanks!
Goooood. This makes the weekend even better. ;-)
Still remain the minor problem in arrangement of IPIPA subnet mask: 169.254.0.0/16 on clients 169.254.0.0/24 on gateway
I don't know where you can see that. The tun interface is a point to point connection ...
Greetings, Marek
PS: 2 hours reponse time isn't that bad, is it ? :) _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Hello,
On Montag 24 September 2007, Michael Burmeister-Brown wrote:
Marek,
I hate to bother you but you were so responsive before...
Antonio just put up a post. We are both seeing the same problem - computers associated with repeaters on 0.3 (MIPS) can't browse. But ssh into that node and do a wget and it works great!. If we just replace 0.3 with 0.2 all works again.
So you want to use the batman-clients as APs for usual 802.11-managed-mode clients. If I understand you right, then you prbably need to do network address translation (NAT) or MASQUERADEing on the bat0 interfaces on the batman clients. And of course a second time on the batman-GW.
Also, I am tracking memory and see it dropping steadily on the nodes (500k in about 12 hours). This didn't happen with 0.2 and that is all that has changed.
Thats interesting, sounds like a memory leak, because in the lates setups i tested the memory consumption was constantly 3.1 percent (even after hours). using dynamically compiled mipsel binaries and up to 20 nodes . Can you send the output from top right after the start, after a few minutes and after a few hours. And the output of debug-level -5 (hope its compiled in)
ciao, axel
Hi,
I hate to bother you but you were so responsive before...
no problem - I'm here. :-)
Antonio just put up a post. We are both seeing the same problem - computers associated with repeaters on 0.3 (MIPS) can't browse. But ssh into that node and do a wget and it works great!. If we just replace 0.3 with 0.2 all works again.
From the client associated to AP_n you can ssh to your gateway ? Than you have
a problem with your internet tunnel.
Also, I am tracking memory and see it dropping steadily on the nodes (500k in about 12 hours). This didn't happen with 0.2 and that is all that has changed.
What do you mean with "memory and see it dropping steadily" ?
Is there any way you can look into this ASAP? We are very close to having to give code to our supplier for the routers and we would very much like to ship with 0.3 rather than 0.2.
And you are sure to preinstall 0.3 ? It is not stable yet. There are a bunch of things to come soon: improved blackhole detection, BATMAN IV, a kernel modul for faster tunneling, bugfixes, etc ... Especially the experimental branch is packed with a lot of additional testing features. I don't know wether it is wise to ship that ...
FYI, we sent you 6 merakis today. I'll get you a tracking number shortly.
Great - thanks.
Regards, Marek
b.a.t.m.a.n@lists.open-mesh.org
-
a.anselmi＠oltrelinux.com -
Axel Neumann -
elektra -
Marek Lindner -
Michael Burmeister-Brown -
Steven Leeman