OpenWrt Forum Archive

Topic: pptpd and bcrelay

The content of this topic has been archived on 25 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Is it possible to get a bcrelay enabled pptpd without builiding it myself?


instead of starting a new topic I'll just use this one because my question is nearly identical.
I'm running pptpd - 1.3.0 at the moment, pretty flawlessly.

The only problem is that broadcasts are not tunneled through the VPN connection.
So I tried to compile the bcrelay binary myself - without success. I found out that the pptd binary in the package 1.3.0-1 is compiled with bcrelay support but of course I still get an error due to the missing bcrelay binary.
The other problem is that I'm not experienced in editing the iptables rules - I don't want to cause security flaws.

I don't know whether there existed a bcrelay binary for mipsel or not (I read somewhere that that there was one available some time ago).

So I'd really appreciate any help I can get in solving this. And it seems that I'm not the only one with this problem sad

Thanks advance and sorry for my bad English...

Pleeeaase. Only a little help with configuring the firewall or if anybody still has the bcrelay binary for mipsel...
It can't be that hard to do what I want to do. It's just that I'd need a little hint.

Desperatly, Simba

Aww, that's so disappointing sad

No info on what happend to the bcrelay binary, no info on iptables, not even anybody screaming "you're an idiot!".
Why? Is my language that bad that nobody gets what I write? Or am I doing something completly wrong?
I really tried to handle those iptables rules and googled and whatnot... for hours!
That are the rules I'm using at the moment for pptp clients... local network and pptp clients are in the same subnet (because of proxy arp which is not working when they're in different ones):

iptables        -A forwarding_rule -s -d -j ACCEPT
iptables        -A output_rule     -o ppp+ -s -d -j ACCEPT
iptables        -A input_rule      -i ppp+ -s -d -j ACCEPT

Are those okay? Is there a security problem when simultanously using pppoe as my WAN connection (ppp+ includes my ppp0 pppoe interface)? If I want to do the rule on every connection I could use the script - but the rules have to be a little different for that, right?

Is iptables able to forward broadcasts? Sadly, I'm not even able to broadcast between br0 and my vlan2 (which should be part of br0 - vlan2 only uses another IP range... 192.168.1.* for local network and pptp and 192.168.0.* for vlan2/port4)

I would be really grateful, if someone could give me some kind of hint.

(Last edited by simba87 on 14 Sep 2007, 12:52)


I also tried to get bcrelay to work with no success.
But as I understood, the bcrelay code got into the pptpd package, or should get into it also for the OpenWrt package.

I've tried to motivate on this for the Freifunk firmware, which is a variant of OpenWrt.
And I can already read it in (todos/ideas): … /ChangeLog .

Unfortunately … mipsel.ipk didn't contain it in the last version I have tested. Got the failure that bcrelay is an unrecognized option. But since the current build is from yesterday, probably something already changed.
Or you will have success in compiling it for this OpenWrt variant.

Normally, such standard packages are compatible with both systems without any problems.




I'm pretty happy that I'm not alone in trying to get that to work (I'm not happy that this is a problem for us, though wink)
As I stated before... there's a pptpd binary for openwrt compiled with bcrelay support, but the bcrelay binary is missing in that package, too.
Are you experienced in compiling for OpenWrt? I have to say that it's painful for me - I'm no C programmer and compiling C/C++ code (even if it's only for x86) is a problem for me.

But my question still remains: Is there any chance to forward the broadcasts by using iptables?

It would be very nice if you could post here if there are any news on how to solve this. Thanks!

How do you see that the bcrelay binary is missing when you use the pptpd binary with bcrelay support?
Because, as I wrote, I only come to an unrecognized option warning.

I'm unfortunately not experienced in compiling for OpenWrt. Even with my knowledge of C. The Buildroot, Linux, etc. is not my environment and I'm missing some relations for effective work on that.
If I get any news (but waiting for them for months) I will tell them.

Alex … mipsel.ipk
The pptpd binary included in this package comes with support for the bcrelay.

# /tmp/pptpd -h

pptpd v1.3.0
Usage: pptpd [options], where options are:

 [-b] [--bcrelay if]       Use broadcast relay for broadcasts comming from.
                           the specified interface (default is eth1).
# /tmp/pptpd -b br0
# logread
Sep 21 13:42:05 (none) kern.err pptpd[710]: MGR: bcrelay binary /usr/sbin/bcrelay not executable

I don't know whether they forgot to include the bcrelay binary or if it was done on purpose.

I've read from integration, splitting, and so on.
So if it's included or not depends on the version I think.

I've found out that dd-wrt also used to have bcrelay, so the binary propably could be transfered from it. But in the actual or in the 1.3.0-1 version.. .
Debian also has mipsel compiled bcrelay versions. Propably it will also work to get it from the .deb package. Unfortunately I have no Debian and currently also no dd-wrt installed anywhere.

Sorry, I forgot to mention that I already tried the bcrelay binary from the debian package (extracted it wit ar -x) I found under
But no luck, though.

# chmod 0755 /tmp/bcrelay
# /tmp/bcrelay -v
-ash: /tmp/bcrelay: not found

(Last edited by simba87 on 27 Sep 2007, 02:56)


I just went ahead and compiled it natively on my WRT54G... it wasn't as hard as I thought it'd be.
But when I compiled it with ./configure --with-bcrelay it wouldn't finish sad
But it still compiled the bcrelay binary even without the --with-bcrelay option.
I don't know if I made a mistake with the linking because the binary is >70kb.

I'll continue to try to cross-compile it with x86... but if you want to have the binary as it is just let me know.

I didn't have time to test it myself but logread says

Sep 24 23:21:18 (none) kern.debug pptpd[837]: CTRL: BCrelay incoming interface is br0
Sep 24 23:21:18 (none) kern.debug pptpd[838]: CTRL (BCrelay Launcher): Launching BCrelay with pid 0
Sep 24 23:21:18 (none) kern.debug pptpd[838]: MGR: BCrelay incoming interface is br0
Sep 24 23:21:18 (none) kern.debug pptpd[838]: MGR: BCrelay outgoing interface is regexp ppp[0-9].*

so I guess it could work smile

Good work!

I've tested the … mipsel.ipk, but unfortunately with no luck.
I'm using freifunk firmware (, which is based on OpenWrt, but not identical to it. So I think that's the reason why it didn't work. I also tried it with the working /etc/init.d/pptpd which already existed, and no luck. But I should test it more. Because I've got the "unrecognized option bcrelay", again.. .

Just write when you have tested it. I'm very interested.
And when it works, I will need the bcrelay binary :-).



Okay, my failure on the "unrecognized option" was to use bcrelay [interface] in the options.pptpd file.
Instead of using it this way I tried it with the -b [interface] option on the pptpd binary which works except for the missing bcrelay binary.
So please, could you provide the one you've compiled :-). (Eventually not only the binary - I think there should be a few more, possibly just useless textfiles.)



After trying to compile it with the SDK for hours I gave up.
I don't know what I'm doing wrong - it just wouldn't work. I would appreciate it if somebody who has the experience could have a look at the wiki entry and make it a little more understandable sad

The good news is that I managed it to cross-compile the pptpd with bcrealy support.
But don't get you hopes I up - I still wasn't able to test it and I still don't know how to get the files as small as they're in the OpenWrt repository. The pptpd binary is >105kb and the bcrelay binary is bigger than the one I compiled natively on the router (>123kb).

If there're any tips on how to solve those problems - I'd be thankful (but I duobt that ther will be any reaction... it seems that I'm too noob-ish to get help sad) … ar.gz.html (I don't know how to create ipkg packages without the sdk)


(Last edited by simba87 on 26 Sep 2007, 19:37)

Probably it is time to try Kamikaze.

In Kamikaze 7.09 pptpd is built by default with bcrelay (pptpd/Makefile, line 35). So you only have to package it, recompile and reinstall the pptpd package.

Index: net/pptpd/Makefile
--- net/pptpd/Makefile  (Revision 9025)
+++ net/pptpd/Makefile  (Arbeitskopie)
@@ -49,6 +49,7 @@
        $(INSTALL_DIR) $(1)/usr/sbin
        $(CP) $(PKG_INSTALL_DIR)/usr/sbin/pptpd $(1)/usr/sbin/
        $(CP) $(PKG_INSTALL_DIR)/usr/sbin/pptpctrl $(1)/usr/sbin/
+       $(CP) $(PKG_INSTALL_DIR)/usr/sbin/bcrelay $(1)/usr/sbin/
        $(INSTALL_DIR) $(1)/usr/lib/pptpd
        $(CP) $(PKG_INSTALL_DIR)/usr/lib/pptpd/* $(1)/usr/lib/pptpd
        $(INSTALL_DIR) $(1)/etc

(Last edited by forum2006 on 26 Sep 2007, 20:02)

Upgrading to Kamikaze is way too much effort for me. There are soo many things on my router from which I not even have a backup that I'm not even thinking about an upgrade (a whole community site with an account database for mail and jabber server controlable via a php frontend runs on it)

However... I don't know what I did wrong, but IT'S WORKING *does the happy dance*
No, I don't mean the actual problem is solved (I still couldn't test the broadcasts via the tunnel) - I mean I was able to cross-compile it with the SDK.
I still don't believe how simple it was (with the whole make pptpd-clean V=99, prepare and compile stuff)

So, why didn't anybody drop me a line with a hint? It took me days just to compile it and I still couldn't test it (although bcrelay starts and I'm able to connect to the pptpd server)
The binaries are now as small as they should be.

Here's the ipkg package … l.ipk.html

Great Work!

Your .ipk works without any problems (using Freifunk Firmware - based on OpenWrt).

So I will test the bcrelay function very soon!

Thank you. I was waiting so long for this package.


I didn't get it to work.

I got no single message like:
Active interface set changed to: br0 ppp0 or
UDP_BroadCast from: ppp0 relayed to: br0

But I can ping the hosts and i.e. shares are also working. So the VPN is okay.
For that I added the route to the VPN subnet on the LAN side and the route to the LAN subnet on the VPN side.
route ADD MASK IF 4
route ADD MASK IF 4

Broadcasts are also seen on the router with tcpdump -i ppp0 ip broadcast.

But something is missing.
Special routes for the broadcasts on Windows or the router?
IpTable rules?

I'll test it tomorrow, too.
However I definitely got a message from logread

Sep 24 23:21:18 (none) kern.debug pptpd[837]: CTRL: BCrelay incoming interface is br0
Sep 24 23:21:18 (none) kern.debug pptpd[838]: CTRL (BCrelay Launcher): Launching BCrelay with pid 0
Sep 24 23:21:18 (none) kern.debug pptpd[838]: MGR: BCrelay incoming interface is br0
Sep 24 23:21:18 (none) kern.debug pptpd[838]: MGR: BCrelay outgoing interface is regexp ppp[0-9].*

In my package I didn't modify the init.d script because of the fact that I wasn't able to test it, but adding "-b br0" did give me the message above. Did you try it with 'pptpd -b br0' (or whatever your interface is)?
When I've tested it I could modify the init.d script - I just wasn't sure about that.

I don't know about the iptables rules but shouldn't iptables itself be able to forward the broadcasts? I asked that very same question a few posts above but until now nobody answered to that. I think that when using bcrelay there's no need for firewall rules.

As I said... I'll test it and come back with results (hopefully postive ones wink)

Okay, it works!
Bcrelay just terminates itself often when the traffic is heavy (or something). (possibly other newer versions can help?)
So it must be started again and again, I did this with a loop and not running as daemon as the pptpd executable starts it.
Only problem so far, some programs use the "wrong" ip to broadcast (other than the vpn ip), which could be set in some settings sometimes. Because normally, there will be no routes back to other interfaces as the vpn one.
If -i ppp0 -o br0 or -i br0 +o ppp0 seems to do not matter, bcrelay relays in both directions (to the adress, even when only coming as a subnet broadcast on the other interface.)

I compiled the latest stable version (1.3.4) of pptpd with bcrelay. The package contains a modified startup script which gets the interface name from a nvram variable.

If there should be any moderator reading... perhaps this could go into the repository.

I still couldn't test bcrelay (the days are really too short hmm) but the connection to the pptpd is working without problems. … l.ipk.html

If there's improvment in stability (hopefully) it'd be nice if you could drop me a line smile

(Last edited by simba87 on 1 Oct 2007, 05:34)

I'm gonna test it later today and will report about the stability soon.

And thanks for the new binary!

v1.3.4 is working much better, bcrelay didn't get killed until now, and I've tested the same heavy traffic as on the last version. So it seems that the instability issue is gone :-).
Reading of the lan interface name from the nvram also works as it should, great addition!

So, now that you definitely know how to build the package, can you give me little advice on that, like a general link on what I have to do, and especially what I have to take care in the special case of pptpd with bcrelay. And which source to use?

Because there are always new versions coming (like the already avalaible 1.3.4-2 which has an "additional patch to fix regression in GRE re-ordering". So if you don't mind to build this one someday, I will test it with enjoyment too.



I wasn't aware that there's a more up to date CVS tree on the sourceforge site - last time I took the source from the .tar.gz under downloads.

I'll make the explanation short because I don't want to waste time with things you already know wink
If there should be questions don't hesitate to ask!
Hopefully I'll not forget anything. It's some days ago since I made the first package...
I took the SDK from … -1.tar.bz2
You can try to build an example from the examples directory or you go ahead and take the package directory
via SVN from … age/pptpd/
This way you don't have to do the work twice.

Now comes the modifying part:
OpenWrt-SDK-Linux-i686-1/package/pptpd/patches - I deleted them because they're for version 1.3.0, aren't they?
OpenWrt-SDK-Linux-i686-1/package/pptpd/Makefile - change PKG_VERSION, PKG_RELEASE and PKG_MD5SUM if you have the MD5 from the new version. This way the package will be downloaded from Sourceforge (identified through PKG_NAME & PKG_VERSION). Add configure options like --enable-bcrelay and delete old ones (like the --with-pppd-ip-alloc that isn't needed since 1.3.1 (there isn't a replacement, right?))
If you want to create a full package you have to avoid that the LIBDIR variable is replaced by the in the pptpd source package. So, delete the export line around line 686.

And if you believe it or not - you're ready to crosscompile the thing.
cd to your OpenWrt-SDK-Linux-i686-1 directory and type
make pptpd-clean V=99
make pptpd-prepare V=99
make pptpd-compile V=99

OpenWrt-SDK-Linux-i686-1/bin/packages should now contain the ipk file.
If there's a more straight forward way then tell me, please smile

*edit* I forgot to add the package for pptpd 1.3.4-2 … l.ipk.html

However, I do have some problems with the pptpd. Connection is stable and everything is working except broadcasts.
What am I doing wrong? I tested the broadcasts with 'ping' from a Windows machine. TCPdump on the router says that they're arriving, but there's no reply to them. When I do this within the LAN then there are replys.

How do you test the UDP broadcasts? I did try uftp, but no success, too.

Here are some parts that could be relevant...

 -- firewall.user --
iptables        -A forwarding_rule -s -d -j ACCEPT
iptables        -A output_rule     -o ppp+ -s -d -j ACCEPT
iptables        -A input_rule      -i ppp+ -s -d -j ACCEPT
 -- pptpd.conf --
 -- options.pptpd --

Is there anything I should add for the broadcast functionality? And I'm no network expert but is there a security risk when using ppp+ (because my WAN connection is ppp0)? BCRelay also says that it forwarded the packages to ppp0 and ppp1 - but ppp0 shouldn't get broadcasts from the LAN. *edit* it just occurred to me... is ppp+ a regular expression? *edit2* No, it doesn't seem to be regex.

I already get

Oct  3 16:32:02 (none) kern.debug pptpd[1140]: CTRL: Made a ECHO RPLY packet
Oct  3 16:32:02 (none) kern.debug pptpd[1140]: CTRL: I wrote 20 bytes to the client.
Oct  3 16:32:02 (none) kern.debug pptpd[1140]: CTRL: Sent packet to client


Oct  3 16:40:13 (none) bcrelay[1289]: UDP_BroadCast(sp=138,dp=138) from: br0 relayed to: ppp0 ppp1

but the packages are not received on the LAN.
If you could post your settings or have a hint, I'd be thankful smile

Sorry for the long post (I hope it's understandable, because English isn't my mother tongue as you've probably noticed wink)

(Last edited by simba87 on 3 Oct 2007, 18:42)

Thank you for the description for compiling the package. I will try this as soon as I have time for it.
But before I'll try the pptpd v1.3.4-2.

Okay, and now what you can do for seeing the broadcasts..

The VPN Client normally does not have a explicit route to the LAN. But the the default route can do it. If not, or there is none, add a route to the whole LAN range via the gateway.
On the LAN client side, the same thing, add a route to the VPN range if the default route can't do it.

Your forwarding and input/output rules should be okay, but don't forget that you also need them from VPN->LAN, LAN->VPN (and what you already have VPN->VPN).
But to avoid any firewall issues while testing, I recommend to deactivate it (i.e. /etc/init.d/S45firewall stop).

On the router, there should be the routes between VPN to LAN, LAN to VPN and VPN to VPN. This can be checked easy by pinging a lan client from vpn, vpn client from lan, and vpn client from vpn. If this works, we should be able to cross the finish line soon.

For testing the broadcasts, I never used ping. And I don't know if it's possible.
Instead you can try Wireshark or something similar which will capture you all packets on the network, and there you can set a filter to only see the two (three) broadcast adresses, i.e. and (and LAN.LAN.LAN.255)

On the LAN side you should than see packets with source IP 192.168.1.x and destination Regardless if they were going to or on the VPN side.
On the VPN side you should see the broadcasts with LAN source address with destination to.

If you capture the packets on both sides, LAN and VPN, you will see what's going on very well.

For testing heavy broadcast traffic I used a game in LAN mode. They often have a Lobby, and there you should see all Users, which is done by broadcasts. In game traffic normally is sent direct.

Good Luck


..and don't complain about your english, it's quite well, I understand everything and it's also not my mother tongue..

The discussion might have continued from here.