OpenWrt port of mcproxy

[noltari]

Hello,

First of all, thanks for developing mcproxy.

I've seen that you have plans to port mcproxy to OpenWrt in the future.

I'm very interested in this, since igmpproxy is very limited.

Here's what I've done so far:

#1 qmake and OpenWrt don't work very well, so I generated a Makefile with qmake and adapted it for OpenWrt.

#2 Sources are downloaded from your Github Repository and #1 Makefile is copied to "mcproxy" directory.

#3 You need to manually install the boost libraries in order to get it to compile: "./scripts/feeds install boost"

#4 You need to manually select gcc-linario 4.8.0 and eglibc 2.17 in order to get mcproxy compiled succesfully, since uClibc is missing required definitions and default gcc 4.6 misses c++11.

Issues:

#1 mcproxy doesn't deal very well with OpenWrt and has several errors detecting them, so it's impossible to test if it works.

#2 I don't know if I should use the alias or the interface itself (e.g. iptv vs eth0.2). mcproxy complains when using dots in VLANs.

Logs:

mcproxy -c

root@OpenWrt:/# mcproxy -c

Check the currently available kernel features.

- root privileges: Ok!

- ipv4 multicast: Ok!

- ipv4 multiple routing tables: Ok!

- ipv4 routing tables: Ok!

- ipv4 mcproxy was able to join 20 groups successfully

- ipv4 mcproxy was able to set 40+ filters successfully (no limit found)

- ipv6 multicast: Ok!

ERROR: failed to set kernel table! Error: Protocol not available errno: 99

- ipv6 multiple routing tables: Failed!

- ipv6 routing tables: Ok!

- ipv6 mcproxy was able to join 40+ groups successfully (no limit found)

- ipv6 mcproxy was able to set 40+ filters successfully (no limit found)

As you can see I forgot to enable IPv6 multicast support :P.

OpenWrt package: https://dl.dropboxusercontent.com/u/4708147/openwrt/packages/mcproxy-openwrt.tgz

Regards,

Álvaro.

[Thomas C. Schmidt]

Hi Álvaro,

many thanks for your input ... and yes, we want to get this ready for
OpenWrt.

Sebastian, our core developer, is on travel these days, but will be back
next week. He'll probably have more to say on the next steps.

Best regards,

thomas

> --
> You received this message because you are subscribed to the Google
> Groups "Multicast Proxy" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to multicast-pro...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

--

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 °

[noltari]

Hi Thomas,

There's no hurry ;).

Meanwhile, I would like to share some updates.

I've created a Github repository with the OpenWrt package files:

https://github.com/Noltari/openwrt-mcproxy

Some detailed steps to get mcproxy built for OpenWrt:

#1 Clone OpenWrt:

git clone git://git.openwrt.org/openwrt.git

#2 Add mcproxy feed to feeds.conf.default:

src-git mcproxy git://github.com/Noltari/openwrt-mcproxy.git

#3 Update feeds:

./scripts/feeds update

#4 Install mcproxy and its dependencies:

./scripts/feeds install mcproxy

#5 Configure OpenWrt (select target and device):

make menuconfig

#6 Enable build of mcproxy:

Network -> Routing and Redirection -> mcproxy

#7 Enable Advanced configuration options for developers:

Advanced configuration options (for developers)

#8 Enable Toolchain options:

Advanced configuration options (for developers) -> Toolchain Options

#9 Select GCC 4.8:

Advanced configuration options (for developers) -> Toolchain Options -> GCC Compiler Version -> gcc 4.8.x (with Linaro enhancements)

#10 Select eglibc:

Advanced configuration options (for developers) -> Toolchain Options -> C Library implementation -> Use eglibc

#11 Select eglibc v2.17:

Advanced configuration options (for developers) -> Toolchain Options -> eglibc version -> eglibc 2.17

#12 Exit and save configuration.

#13 Build openwrt:

Parallel build of toolchain with eglib seems to be broken, so if "make -jX V=s" fails, retry with "make V=cs"

BTW, one of the first steps needed is modifying mcproxy in order to accept interfaces like ethX.Y (since it complains when using dots, and this is the standard name used in OpenWrt when using VLANs).

Regards,

Álvaro.

[Sebastian Wölke]

Hello Álvaro,

thanks for your help!

I updated the master branch. If you put the interface names in quotes like
pinstance foo: "eth0.1" ==> "eth0.2" "bar-.123" eth3 eth4;
the mcproxy should accept them.

The next thing I can do is to remove the dependencies to the boost library.

Kind regards,
Sebastian

[noltari]

Hello Sebastian,

First of all you're welcome, and I should be the one thanking you for developing mcproxy ;).

Speaking of your latest update, now OpenWrt interfaces are correctly recognised ("ethX.Y" and even "br-lan").

Good work!

I could get mcproxy on a Comtrend VR-3025u (which isn't officially supported by OpenWrt, but since it has 32MB of flash I don't have any space limitations - eglibc, boost libraries and mcproxy are pretty big).

Execution log: https://dl.dropboxusercontent.com/u/4708147/openwrt/packages/mcproxy/log/mcproxy_001.txt

I could even see IPTV through IGMPv3 on several devices, as you can see on the log for addresses like 239.0.9.131, 239.0.9.134...

However, there's a weird issue: I must boot the router, run mcproxy and connect the WAN wire, preventing the interfaces from being up before running mcproxy.

If I run mcproxy after the interfaces have been initialized, it will crash with a Segmentation fault.

Any idea on what could be happening?

Is this OpenWrt realted or also happens on other OS?

BTW, I don't know why but whenever I select IGMPv1 or IGMPv2, mcproxy complains about "Protocol not supported" :/.

And I don't think you should remove boost libraries for now, since that would imply a lot of work, and it doesn't really solve any issue (OpenWrt has full support of those libraries).

Regards,

Álvaro.

[noltari]

Hello again,

I've seen that you have removed the boost libraries dependencies.

mcproxy has been significantly reduced in size, which is very nice for OpenWrt, since routers usually have little space in flash.

BTW, I checked the code and now I understand why it says protocol not supported for IGMP v1 and v2, sorry for being so lazy and not checking it before :P.

I thought you've kept compatibility for the older protocol on the new versions.

Finally, I need to investigate the reason of the "Segmentation fault" when mcproxy is run after the interface has been initialized.

Disconnecting the WAN wire and doing ifdown iptv && ifup iptv, running mcproxy and connecting the WAN port again works.

Regards,

Álvaro.

[noltari]

I managed to find the cause of the Segmentation Fault:

First I realized that if I did "killall pppd && mcproxy -f mcproxy.conf" everything worked perfectly.

Then I started to review the code and in configuration.cpp->initalize_interfaces() there's this line:

auto result = std::make_shared<interfaces>(get_addr_family(m_gmp), m_reset_reverse_path_filter);

When the interfaces are created, the code tries to reset them by calling "m_if_prop.refresh_network_interfaces()" and something goes wrong (PPP interfaces only?), launching an exception and causing the segmentation fault in make_shared.

I have to investigate why this happens.

Regards,

Álvaro.

[noltari]

Okay, I finally was able to find the cause of the Segmentation fault and fixed it.

I created a pull request:

https://github.com/mcproxy/mcproxy/pull/1

Regards,

Álvaro.

[Sebastian Wölke]

Hello Álvaro,

thank you very much. I merged it.

Kind Regards,
Sebastian

[noltari]

Hello Sebastian,

I think that the following steps should be:

1) Adding an option to reduce the output log in order to only show errors, since mcproxy output is too much for an embedded device.

2) Adding support for IGMPv1, IGMPv2 and MLDv1, since OpenWrt developers usually reject "half done" stuff.

BTW, OpenWrt has removed support for eglibc 2.16 and 2.17, and they have added support for 2.19, which replaces 2.15 as the default version when selecting eglibc.

This means that we no longer need to manually select the latest version, but we still need to switch from uclibc to eglibc (e.g. setsourcefilter/getsourcefilter isn't available in uclibc).

Appart from that, I think it would be a good idea to wait until they switch to gcc 4.8 as the default compiler, before sending the mcproxy package.

Regards,

Álvaro.

[Sebastian Wölke]

Hello Álvaro,

To 1):

If you compile the proxy without the DEBUG-flag all ERROR messages will be forwarded to the cerr-stream and should be visible in the terminal output.
And I updated the master branch. Status messages will only be printed if you explicitly add the paramenter -s as described in the help output/docu. Thanks for the hint.

To 2):

I think I can implement the backward compatibility to IGMPv1/2 and MLDv1 next week.

Regards,
Sebastian

[noltari]

Hello Sebastian,

Thanks for your feedback and nice work :D.

I have some good news to share.

I was able to compile mcproxy with uclibc (OpenWrt default library. Size is ~200k vs 1MB eglibc).

First, I had to remove the code shown here: https://github.com/mcproxy/mcproxy/pull/3

For some odd reason it complains about printf with uclibc but it doesn't with eglibc (maybe because it isn't wrapped as C code? :/).

After that I had to convert all references to stoi, because uclibc complains about this too, which is weird, since I thought it would be related only to gcc version :?.

https://dl.dropboxusercontent.com/u/4708147/openwrt/packages/mcproxy/patches/100-stoi_remove.patch

And finally, I had to define the sourcefilter functions, since those aren't available in uclibc:

https://dl.dropboxusercontent.com/u/4708147/openwrt/packages/mcproxy/patches/200-add_sourcefilter_funs.patch

I tested it and everything worked without any problems.

So, the only toolchain requisite now is related to gcc version, but I don't think that OpenWrt developers will stick to gcc 4.6 as the default version for much longer.

BTW, I have to do some code cleaning on the posted patches.

Oh, and these patches are OpenWrt specific, so no need to commit them to the official mcproxy repository, since those are pretty ugly hacks to save space by avoiding eglibc.

Regards,

Álvaro.

El miércoles, 26 de febrero de 2014 15:21:00 UTC+1, Sebastian Wölke escribió:

Hello Álvaro,

[Sebastian Wölke]

 Hello Álvaro,

great!

I would like to merge your pull request after the implementation of the backward compatibility. Because it is a old debugging code snippet, whose output looks exactly like the wireshark buffer output that is sometimes very usefull.

Thanks,
Sebastian

[Sebastian Woelke]

>>> https://github.com/mcproxy/mcproxy/pull/1 [1]

>>>
>>> Regards,
>>> Álvaro.
>>>
>>> El viernes, 21 de febrero de 2014 13:36:27 UTC+1, noltari escribió:
>>>
>>>> I managed to find the cause of the Segmentation Fault:
>>>>
>>>> First I realized that if I did "killall pppd && mcproxy -f
>>>> mcproxy.conf" everything worked perfectly.
>>>> Then I started to review the code and in
>>>> configuration.cpp->initalize_interfaces() there's this line:
>>>> auto result = std::make_shared<interfaces>(get_addr_family(m_gmp),
>>>> m_reset_reverse_path_filter);
>>>>
>>>> When the interfaces are created, the code tries to reset them by
>>>> calling "m_if_prop.refresh_network_interfaces()" and something goes
>>>> wrong (PPP interfaces only?), launching an exception and causing the
>>>> segmentation fault in make_shared.
>>>>
>>>> I have to investigate why this happens.
>>>>
>>>> Regards,
>>>> Álvaro.
>

> --
> You received this message because you are subscribed to the Google
> Groups "Multicast Proxy" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to multicast-pro...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out [2].
>
>
> Links:
> ------
> [1]
> https://www.google.com/url?q75https%3A%2F%2Fgithub.com%2Fmcproxy%2Fmcproxy%2Fpull%2F146sa75D46sntz�75146usg75AFQjCNGBwzE8oKU6JjFfFdydiDsW3d64GA
> [2] https://groups.google.com/groups/opt_out

[noltari]

Ok, no worries ;)

Just a little update, OpenWrt has officially switched to gcc-4.8 as the default version, so we no longer need to change the default compiler options.

https://dev.openwrt.org/changeset/39860

BTW, I did some tests to reduce mcproxy size and by removing the following "test functions" the size was decreased from 722.364 bytes to 554.703 (-24%):

main.cpp
	test_log
	test_test
parser/configuration.cpp
	test_configuration
proxy/check_if.cpp
	test_check_if
proxy/membership_db.cpp
	test_arithmetic
proxy/proxy_instance.cpp
	test_querier
	quick_test
	test_a
	test_b
	test_c
	test_d
	rand_test
proxy/simple_routing_data
	test_simple_routing_data
proxy/timers_values.cpp
	test_timers_values
	test_timers_values_copy
proxy/timing.cpp
	test_timing
proxy/worker.cpp
	test_worker
utils/addr_storage.cpp
	test_addr_storage_a
	test_addr_storage_b
utils/if_prop.cpp
	test_if_prop
utils/mc_socket.cpp
	test_mc_group_functions
	test_mc_source_delta_based_api
	test_mc_source_advanced_api
	test_all
utils/mroute_socket.cpp
	test_mcrouter_mrt_flag
	test_add_vifs
	test_del_vifs
	test_add_route
	test_del_route
	test_mcrouter_vifs_routes
	quick_test

If you really need these functions for testing I can make a pull request wrapping them with a define check ("#ifdef TESTER").

On the other hand, if you don't need those functions I can make a pull request deleting them.

And if you want me to wait until you've added support for IGMPv2/MLDv1 just tell me :P.

Regards,

Álvaro.

[Sebastian Wölke]

Hello Álvaro,

I have updated the master branch and the backward compatibility should be available now.

And wow 24% is a lot. I'm not sure how usefull it is, but if the mcproxy runs only in the backround all to_string() functions and all long error messages are useless, too, so a precompiler flag for that code could reduce the binary size again.

I going to try it tomorrow.

Regards,
Sebastian

[noltari]

Hello Sebastian,

I have updated my next branch and created a pull request with the changes I proposed before and a typo fix:

https://github.com/mcproxy/mcproxy/pull/5

BTW, I deleted the previous pull request, since it isn't needed anymore.

On the other hand I did some tests with a "not finished version" of the backward compatibility implementation, but I have yet to test the final version.

Lastly, I'm not sure if I did something wrong and I know that checking the code I could solve this doubt, but you know the code better :P:

What happens if one interface has several IPs?

For the tests that I did, there were some troubles and it looked like only the devices on the subnet corresponding to the main IP were working perfectly (first IP added to the interface).

Regards,

Álvaro.

El viernes, 14 de marzo de 2014 02:04:39 UTC+1, Sebastian Wölke escribió:

Hello Álvaro,

[Sebastian Wölke]

Hello Álvaro,

Thank you very much for the pull request.

 > What happens if one interface has several IPs?

The source address of join and leave messages for the membership aggregation are handled by the linux kernel (you're right, usually the first address of the interfaces).
And for the query messages at the downstream/querier side the mcproxy is also configured to use the first address.

What kind of trouble do you have and which IP version do you use?

Kind Regards,
Sebastian

[noltari]

Hello Sebastian,

First of all, I have updated the OpenWrt package to the latest version, which is based on your memory_minimisation branch:

https://github.com/Noltari/openwrt-mcproxy/commit/ef4e29999bb2900db28b39af8299dea2bcff3340

The trouble I have is related to the IPTV decoders of my ISP.

My ISP assigns an alias to the LAN interface (10.x.y.z/29), which is used only for the TV decoders, instead of using the normal 192.168.1.0/24 subnet.

For some odd reason, those devices can't subscribe to a multicast address if the alias IP is not the main IP of LAN.

P.D: IPv4, and I've tried with IGMPv2 (since the IPTV decoders are supposed to be IGMPv2) and with IGMPv3.

Regards,

Álvaro.

[Sebastian Wölke]

Hello Álvaro,

oh oh, yes I see. Its a bug of the mcproxy.
The mcproxy receives the join message, but of some reason it is not possible to get the interface interface index of the receiver interface (IPv4 socket problem) which is necessary to asign it to a querier. Instead I have to map the source address of the join message to a subnet of the related interface. Here is the bug. I just check if the first address/subnet of the interface in in the same subnet as the join message. I will fix it.

Kind Regards,
Sebastian

[Sebastian Woelke]

Hello Álvaro,

I have bad news for you. The message I sent you before is only relevant
for the old mcproxy version 0.1.5. In all newer versions this problem is
already fixed.
I overworked a few things but it schould not solve any probelm.

So I have currently no idea what's the problem.
Can you monitor with wireshark the connection to your IPTV decoder,
maybe it sends join messages with a wrong checksum.
Or if it is possible to activate the debug mode you could look for the
debug output "received packet XXXXXXXXXXXXXXXXXXXXXXXXXXXXX" in one of
the log files, maybe the mcproxy drops the packet for some other reason.

Kind Regards,
Sebastian

Am 18.03.2014 14:14 schrieb Sebastian Wölke:
> Hello Álvaro,
>
> oh oh, yes I see. Its a bug of the mcproxy.
> The mcproxy receives the join message, but of some reason it is not
> possible to get the interface interface index of the receiver
> interface (IPv4 socket problem) which is necessary to asign it to a
> querier. Instead I have to map the source address of the join message
> to a subnet of the related interface. Here is the bug. I just check if
> the first address/subnet of the interface in in the same subnet as the
> join message. I will fix it.
>
> Kind Regards,
> Sebastian
>
> Am Dienstag, 18. März 2014 11:32:47 UTC+1 schrieb noltari:
>
>> Hello Sebastian,
>>
>> First of all, I have updated the OpenWrt package to the latest
>> version, which is based on your memory_minimisation branch:
>> https://github.com/Noltari/openwrt-mcproxy/commit/ef4e29999bb2900db28b39af8299dea2bcff3340

>> [2]

>>
>> The trouble I have is related to the IPTV decoders of my ISP.
>> My ISP assigns an alias to the LAN interface (10.x.y.z/29), which is
>> used only for the TV decoders, instead of using the normal

>> 192.168.1.0/24 [3] subnet.

>> For some odd reason, those devices can't subscribe to a multicast
>> address if the alias IP is not the main IP of LAN.
>>
>> P.D: IPv4, and I've tried with IGMPv2 (since the IPTV decoders are
>> supposed to be IGMPv2) and with IGMPv3.
>>
>> Regards,
>> Álvaro.
>>
>> El lunes, 17 de marzo de 2014 17:36:31 UTC+1, Sebastian Wölke
>> escribió:
>>
>>> Hello Álvaro,
>>>
>>> Thank you very much for the pull request.
>>>
>>>> What happens if one interface has several IPs?
>>> The source address of join and leave messages for the membership
>>> aggregation are handled by the linux kernel (you're right, usually
>>> the first address of the interfaces).
>>> And for the query messages at the downstream/querier side the
>>> mcproxy is also configured to use the first address.
>>>
>>> What kind of trouble do you have and which IP version do you use?
>>>
>>> Kind Regards,
>>> Sebastian
>>>
>>> On Saturday, March 15, 2014 2:19:09 AM UTC+1, noltari wrote:
>>>
>>>> Hello Sebastian,
>>>>
>>>> I have updated my next branch and created a pull request with the
>>>> changes I proposed before and a typo fix:

>>>> https://github.com/mcproxy/mcproxy/pull/5 [1]

> --
> You received this message because you are subscribed to a topic in

> the Google Groups "Multicast Proxy" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/multicast-proxy/nKJ9sQaoz7c/unsubscribe
> [4].
> To unsubscribe from this group and all its topics, send an email to
> multicast-pro...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout [5].
>
>
> Links:
> ------
> [1]
> https://www.google.com/url?q75https%3A%2F%2Fgithub.com%2Fmcproxy%2Fmcproxy%2Fpull%2F546sa75D46sntz�75146usg75AFQjCNE9ifje0YenvRXRLIOTNXSchTBu7A
> [2]
> https://www.google.com/url?q75https%3A%2F%2Fgithub.com%2FNoltari%2Fopenwrt-mcproxy%2Fcommit%2Fef4e29999bb2900db28b39af8299dea2bcff334046sa75D46sntz�75146usg75AFQjCNEQ8n3Oj9hXZLF4q7o73af_Lre5Dg
> [3]
> http://www.google.com/url?q75http%3A%2F%2F192.168.1.0%2F2446sa75D46sntz�75146usg75AFQjCNHGv0kuFjHRqP7t4_PcGqrYIfWtqw
> [4]
> https://groups.google.com/d/topic/multicast-proxy/nKJ9sQaoz7c/unsubscribe
> [5] https://groups.google.com/d/optout

[noltari]

Okay, I will look into it after we send it to the official OpenWrt developers ;).

It's not a big deal, since my problem can be easily workarounded by setting the main IP as the IPTV decoders one.

BTW, I opened a new pull request, adding support for killing mcproxy when it hasn't been configured.

This is important in OpenWrt, since we don't want unconfigured stuff to be running and consuming resources :P.

P.S: I think this is the last step needed before sending the package to the official repositories.

Regards,

Álvaro.

[Sebastian Woelke]

Hello Álvaro,

great, I merged the request.

Kind Regards,
Sebastian

>>>> [1]

>>>> [2]
>>>>
>>>> The trouble I have is related to the IPTV decoders of my ISP.
>>>> My ISP assigns an alias to the LAN interface (10.x.y.z/29), which
>>>> is
>>>> used only for the TV decoders, instead of using the normal

>>>> 192.168.1.0/24 [2] [3] subnet.

>>>> For some odd reason, those devices can't subscribe to a multicast
>>>> address if the alias IP is not the main IP of LAN.
>>>>
>>>> P.D: IPv4, and I've tried with IGMPv2 (since the IPTV decoders are
>>>> supposed to be IGMPv2) and with IGMPv3.
>>>>
>>>> Regards,
>>>> Álvaro.
>>>>
>>>> El lunes, 17 de marzo de 2014 17:36:31 UTC+1, Sebastian Wölke
>>>> escribió:
>>>>
>>>>> Hello Álvaro,
>>>>>
>>>>> Thank you very much for the pull request.
>>>>>
>>>>>> What happens if one interface has several IPs?
>>>>> The source address of join and leave messages for the membership
>>>>> aggregation are handled by the linux kernel (you're right, usually
>>>>> the first address of the interfaces).
>>>>> And for the query messages at the downstream/querier side the
>>>>> mcproxy is also configured to use the first address.
>>>>>
>>>>> What kind of trouble do you have and which IP version do you use?
>>>>>
>>>>> Kind Regards,
>>>>> Sebastian
>>>>>
>>>>> On Saturday, March 15, 2014 2:19:09 AM UTC+1, noltari wrote:
>>>>>
>>>>>> Hello Sebastian,
>>>>>>
>>>>>> I have updated my next branch and created a pull request with the
>>>>>> changes I proposed before and a typo fix:

>>>>>> https://github.com/mcproxy/mcproxy/pull/5 [3] [1]

>>> For more options, visit https://groups.google.com/d/optout [5] [5].

>>>
>>>
>>> Links:
>>> ------
>>> [1]
>>> https://www.google.com/url?q75https%3A%2F%2Fgithub.com%2Fmcproxy%2Fmcproxy%2Fpull%2F546sa75D46sntz

>>> [6]�75146usg75AFQjCNE9ifje0YenvRXRLIOTNXSchTBu7A
>>> [2]
>>> https://www.google.com/url?q75https%3A%2F%2Fgithub.com%2FNoltari%2Fopenwrt-mcproxy%2Fcommit%2Fef4e29999bb2900db28b39af8299dea2bcff334046sa75D46sntz
>>> [7]�75146usg75AFQjCNEQ8n3Oj9hXZLF4q7o73af_Lre5Dg
>>> [3]
>>> http://www.google.com/url?q75http%3A%2F%2F192.168.1.0%2F2446sa75D46sntz
>>> [8]�75146usg75AFQjCNHGv0kuFjHRqP7t4_PcGqrYIfWtqw
>>> [4]
>>> https://groups.google.com/d/topic/multicast-proxy/nKJ9sQaoz7c/unsubscribe
>>> [4]
>>> [5] https://groups.google.com/d/optout [5]

>
> --
> You received this message because you are subscribed to a topic in
> the Google Groups "Multicast Proxy" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/multicast-proxy/nKJ9sQaoz7c/unsubscribe
> [4].
> To unsubscribe from this group and all its topics, send an email to
> multicast-pro...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout [5].
>
>
> Links:
> ------
> [1]

> https://www.google.com/url?q75https%3A%2F%2Fgithub.com%2FNoltari%2Fopenwrt-mcproxy%2Fcommit%2Fef4e29999bb2900db28b39af8299dea2bcff334046sa75D46sntz�75146usg75AFQjCNEQ8n3Oj9hXZLF4q7o73af_Lre5Dg
> [2]
> http://www.google.com/url?q75http%3A%2F%2F192.168.1.0%2F2446sa75D46sntz�75146usg75AFQjCNHGv0kuFjHRqP7t4_PcGqrYIfWtqw
> [3]
> https://www.google.com/url?q75https%3A%2F%2Fgithub.com%2Fmcproxy%2Fmcproxy%2Fpull%2F546sa75D46sntz�75146usg75AFQjCNE9ifje0YenvRXRLIOTNXSchTBu7A

> [4]
> https://groups.google.com/d/topic/multicast-proxy/nKJ9sQaoz7c/unsubscribe
> [5] https://groups.google.com/d/optout

> [6]
> https://www.google.com/url?q75https%3A%2F%2Fgithub.com%2Fmcproxy%2Fmcproxy%2Fpull%2F546sa75D46sntz
> [7]
> https://www.google.com/url?q75https%3A%2F%2Fgithub.com%2FNoltari%2Fopenwrt-mcproxy%2Fcommit%2Fef4e29999bb2900db28b39af8299dea2bcff334046sa75D46sntz
> [8]
> http://www.google.com/url?q75http%3A%2F%2F192.168.1.0%2F2446sa75D46sntz

[noltari]

Hello Sebastian,

Awesome!

Pull request sent: https://github.com/openwrt-routing/packages/pull/21

I hope they accept it on the routing & redirection repository, which I think is the proper one for mcproxy.

Regards,

Álvaro.

[noltari]

Hello again,

Excuse me for taking so long to update this but I've been pretty busy...

mcproxy was added to openwrt-routing repository some days ago, with some changes (there was a misunderstanding).

Today I opened another pull request with some fixes and cleanups and it has already been merged: https://github.com/openwrt-routing/packages/commits/master

Now you can erase the OpenWrt port from the TODO list :D.

Regards,

Álvaro.

[sivapr...@gmail.com]

Hi Alvaro

 

Thanks a lot for your valuable reply. It helped me a lot.

 

I am trying to compile openwrt mcproxy for ARM linux .

 

When I try to compile mcproxy using below commands, it is compiling for x86.

1.       qmake mcproxy.pro

2.       Make

 

But my requirement is to compile for ARM . Could you please help me with the Makefile , or the how to generate ARM compatible makefile from qmake .

 

Please help me in this issue.

Regards

Siva Prasad

[sivapr...@gmail.com]