no gateway entry leads to no asterisk calls

86 views
Skip to first unread message

David Rowe

unread,
Apr 4, 2010, 7:36:31 PM4/4/10
to village-...@googlegroups.com
On one of my MP01s I am testing for the Dili VT I discovered that
Asterisk could no longer make or receive calls. This was the MP01
10.130.1.8 that I had configured to connect to a Wifi AP. So I had
messed with /etc/config/network quite a bit.

Here are the symptoms:

1/ After a fresh reboot when you try to dial a number you see this as
the Asterisk CLI (set debug 3):

-- extension exists, starting PBX 8
-- Executing [8@default:1] Dial("MP/1", "SIP/40...@10.130.1.8") in
new stack
[Dec 11 17:29:16] WARNING[597]: chan_sip.c:1775 __sip_xmit: sip_xmit of
0x585a88 (len 772) to 10.130.1.8:5060 returned -2: Bad file descriptor
-- Called 40...@10.130.1.8

Asterisk can not make or receive a call.

2/ Restarting Asterisk fixes it:

root@OpenWrt:/# /etc/init.d/asterisk stop
root@OpenWrt:/# /etc/init.d/asterisk start

3/ But rebooting the MP01 kills it again.

After 2 hours of frustration I traced the problem to the gateway line
in /etc/config/network:

4/ This makes Asterisk work OK after a reboot:

config 'interface' 'lan'
option 'ifname' 'eth0'
option 'proto' 'static'
option 'netmask' '255.255.255.0'
option 'ipaddr' '192.168.1.20'
option 'gateway' '192.168.1.20'
option 'dns' '10.130.1.1'

5/ Removing the gateway entry leads to the problems above:

config 'interface' 'lan'
option 'ifname' 'eth0'
option 'proto' 'static'
option 'netmask' '255.255.255.0'
option 'ipaddr' '192.168.1.20'
option 'dns' '10.130.1.1'

I had removed the gateway option as it serves no function on my network,
Internet is delivered via the mesh using batman tunnelling magic.

This problem occurs on 2/2 of the MP01s I tested.

However Asterisk seems to like the gateway option when it starts for
reasons I can't explain. Given (2) some sort of race condition? Or
maybe Asterisk always needs a default gateway.

6/ Another point I noticed is that Asterisk starts before batman is up:

root@OpenWrt:/etc/rc.d# ls
K40network S39usb S50httpd S90batmand
K99umount S40network S50telnet S95done
S05luci_fixtime S50asterisk S59luci_ethers S97watchdog
S10boot S50cron S59luci_hosts S99fallback-ip
S20fstab S50dropbear S60led S99sysctl

However Asterisk takes quite a while to actually start (it boots in
parallel to the other processes. So the actual state of the network
while Asterisk boots is unknown, e.g. Internet connectivity and DNS
might come up half way thru the Asterisk boot sequence.

Anyway, 10.130.1.8 can make phone calls again now.

Cheers,

David


elektra

unread,
Apr 4, 2010, 9:18:17 PM4/4/10
to village-...@googlegroups.com
Hello David -

> -- extension exists, starting PBX 8
> -- Executing [8@default:1] Dial("MP/1", "SIP/40...@10.130.1.8") in
> new stack
> [Dec 11 17:29:16] WARNING[597]: chan_sip.c:1775 __sip_xmit: sip_xmit of
> 0x585a88 (len 772) to 10.130.1.8:5060 returned -2: Bad file descriptor
> -- Called 40...@10.130.1.8


Asterisk insists on a default routing entry being present in the default
routing table #255 - even if all we want to do is call a link-local IP or a
subnet where we have an explicit route to.

It is completely irrelevant for Asterisk whether this default routing entry in
table #255 is actually working or not.

In the default setting of the MP firmware there is a dummy default routing
entry set to 192.168.1.20, while the local Ethernet IP is 192.168.1.20. This
setting is complete nonsense, of course. But it keeps Asterisk happy... It
does not interfere when Batman is setting a default route. Internet traffic
handled by Batman never reaches table #255 because it is already handled in a
earlier table. And there is no harm, of course, if we replace the dummy entry
with a valid default route.

As as sidenote: Asterisk insists to call the "route" command. Removing the
"route" applet from Busybox will result in the same or a similar Asterisk
error.

Asterisk is not agnostic of policy routing or iproute2. "route" is outdated
and superfluous since iproute2, "route" does not support policy routing, as it
is too old.

Batman uses the Linux policy routing capability, it does not add a default
route to table #255. So we have to make Asterisk believe that there is a
default route in #255, even if it is disfunctional.

Cheers,
Elektra


David Rowe

unread,
Apr 5, 2010, 12:37:50 AM4/5/10
to village-...@googlegroups.com
Hi Elektra,

> Asterisk insists on a default routing entry being present in the default
> routing table #255 - even if all we want to do is call a link-local IP or a
> subnet where we have an explicit route to.

Sounds reasonable but not quite what I am experiencing.

Please see (2) in my original email of this thread. If I restart
Asterisk (on a MP01 with no default route) I can make calls OK. So this
odd behaviour is somehow related to booting Asterisk and batman at
approximately the same time.

Maybe by the time I restart Asterisk batman has provided something close
to a default route that satisfies Asterisk.

Thanks,

David


elektra

unread,
Apr 5, 2010, 5:50:38 AM4/5/10
to village-...@googlegroups.com
Hi David -

> Please see (2) in my original email of this thread. If I restart
> Asterisk (on a MP01 with no default route) I can make calls OK. So this
> odd behaviour is somehow related to booting Asterisk and batman at
> approximately the same time.

since the problem occurs if you remove the default route in routing table
#255, I'd suggest to always keep a default route entry.


> Maybe by the time I restart Asterisk batman has provided something close
> to a default route that satisfies Asterisk.

We should not rely on Batman finding a default route to 0.0.0.0/0 or adding
any other routes before starting Asterisk. By default Batman is configured not
to add a default route to the routing table. A mesh may or may not have a
Internet uplink. A MP might be a device in a small setup that gets booted
hours or days before any other device, or it might be temporarily out of
range.

Cheers,
Elektra

Mike Jensen

unread,
Apr 10, 2010, 1:45:27 PM4/10/10
to village-...@googlegroups.com
I'm still getting the asterisk defaultroute sip error:

[Dec 11 18:47:12] WARNING[642]: chan_sip.c:1775 __sip_xmit: sip_xmit of
0x586fb8 (len 788) to 10.130.1.128:5060 returned -2: Bad file descriptor

despite having dns and a gateway/defaultroute set. Here's my
/etc/config/network:

config 'interface' 'loopback'
option 'ifname' 'lo'
option 'proto' 'static'
option 'ipaddr' '127.0.0.1'
option 'netmask' '255.0.0.0'

config 'interface' 'lan'
option 'ifname' 'eth0'
option 'proto' 'static'
option 'netmask' '255.255.255.0'
option 'ipaddr' '192.168.1.20'

option 'dns' '192.168.1.20'

config 'interface' 'wifi0'
option 'ifname' 'ath0'


option 'proto' 'static'
option 'netmask' '255.255.255.0'

option 'ipaddr' '10.130.1.128'
option 'dns' '192.168.50.1'
option gateway '0.0.0.0'

I also tried on interface wifi0:
option gateway '192.168.1.20'

BTW on the new r233 release, "/etc/init.d/batmand restart" gives:

sh: you need to specify whom to kill :-)

Mike

elektra wrote, On 10-04-04 10:18 PM:

elektra

unread,
Apr 10, 2010, 1:54:23 PM4/10/10
to village-...@googlegroups.com
Hello Mike -

> despite having dns and a gateway/defaultroute set. Here's my
> /etc/config/network:

don't set the gw on WiFi - and don't use 0.0.0.0. Use something in the
192.168.1.0 range on the LAN.

> BTW on the new r233 release, "/etc/init.d/batmand restart" gives:
>
> sh: you need to specify whom to kill :-)

Uuups ;)

Did you succeed flashing the third MP?

Cheers,
Elektra

Pascal Laurent

unread,
Apr 10, 2010, 4:28:57 PM4/10/10
to village-...@googlegroups.com
Mike,

I use to have a similar issue. Upgrading to the latest firmware seems to fix it. I kept a little doc handy while working on my MP setup. The attach doc may help you. Please note it is not completed. Feel free to add to it, fix it, and repost it.

Enjoy,
--P 


Cheers,
Elektra

--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To post to this group, send email to village-...@googlegroups.com.
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/village-telco-dev?hl=en.


afrimesh_mp_network.rtf

Mike Jensen

unread,
Apr 11, 2010, 12:37:02 PM4/11/10
to village-...@googlegroups.com
Elektra wrote:

> don't set the gw on WiFi - and don't use 0.0.0.0. Use something in the
> 192.168.1.0 range on the LAN.

Pascal wrote:
> I use to have a similar issue. Upgrading to the latest firmware seems
> to fix it. I kept a little doc handy while working on my MP setup. >
> The attach doc may help you. Please note it is not completed. Feel >
> free to add to it, fix it, and repost it.


Thanks both! that worked, when I tried adding the MP's IP as the gateway
address as well:

config 'interface' 'lan'
option 'ifname' 'eth0'
option 'proto' 'static'
option 'netmask' '255.255.255.0'

option 'ipaddr' '192.168.3.20'
option 'dns' '192.168.50.1'
option gateway '192.168.3.20'


However that doesn't seem to allow me to also use the MP's LAN port for
traffic from laptops using a WiFi AP connected to it..

I still get:

-- Executing [128@default:1] Dial("MP/1", "SIP/40...@10.130.1.128") in
new stack
[Apr 8 14:36:47] WARNING[599]: chan_sip.c:1775 __sip_xmit: sip_xmit of
0x587598 (len 788) to 10.130.1.128:5060 returned -2: Bad file descriptor


My ath0 config is:


config 'interface' 'wifi0'
option 'ifname' 'ath0'
option 'proto' 'static'
option 'netmask' '255.255.255.0'
option 'ipaddr' '10.130.1.128'
option 'dns' '192.168.50.1'


Mike


David Rowe

unread,
Apr 11, 2010, 6:54:56 PM4/11/10
to village-...@googlegroups.com
Hello Mike,

As per the earlier posts on this thread I have also struggled with this
bug. While I can't explain your current problem Mike, I do have a
working configuration that is very similar to what you are trying to
achieve (Wifi AP connected to a MP01, used for Internet access over the
mesh).

I am in the process of documenting this configuration as part of the
Dili Village Telco wiki:

http://dili.villagetelco.org/index.php?title=Dili_Village_Telco#Network_Design_and_Device_Configuration

It's a work in progress, and I still need to proof read and fix some
typos.

One small difference - I use a DNS server running on the Supernode. In
your case the Supernode can probably by another MP.

Cheers,

David

Reply all
Reply to author
Forward
0 new messages