9:12 a.m.
Hi,
I built the connman from git source upstream, but I could not run it:
$ CONNMAN_WEB_DEBUG=1 src/connmand -d -n -c /etc/connman/main.conf
Failed to create storage directory: No such file or directory
Connection ":1.163" is not allowed to own the service "net.connman"
due to security policies in the configuration file
Where is the storage directory? Do I have to run it in root?
Actually, I've just ran it in root, still could not find storage and crashed:
Failed to create storage directory: No such file or directory
......................
connmand[23886]: Aborting (signal 11) [src/connmand]
Thank you.
Kind regards,
- jh
9:29 a.m.
Hi JH,
On 19.03.19 10:12, JH wrote:
Hi,
I built the connman from git source upstream, but I could not run it:
$ CONNMAN_WEB_DEBUG=1 src/connmand -d -n -c /etc/connman/main.conf
Failed to create storage directory: No such file or directory
Connection ":1.163" is not allowed to own the service "net.connman"
due to security policies in the configuration file
ConnMan needs to run as root.
Where is the storage directory? Do I have to run it in root?
/var/lib/connman is usually the default directory. And yes, ConnMan
needs root or the capabilities defined in the systemd service file.
Actually, I've just ran it in root, still could not find storage
and crashed:
Failed to create storage directory: No such file or directory
......................
connmand[23886]: Aborting (signal 11) [src/connmand]
Urgh, that's bad. Can you attache the debugger and post the complete
backtrace?
Thanks,
Daniel
10:44 a.m.
On 3/19/19, Daniel Wagner <wagi(a)monom.org> wrote:
ConnMan needs to run as root.
> Where is the storage directory? Do I have to run it in root?
/var/lib/connman is usually the default directory. And yes, ConnMan
needs root or the capabilities defined in the systemd service file.
Thanks Daniel, that did the trick.
> connmand[23886]: Aborting (signal 11) [src/connmand]
Urgh, that's bad. Can you attache the debugger and post the complete
backtrace?
It was built from the latest git upstream, running on Ubuntu 18.04,
but I set all --prefix=${BUILD} --sysconfdir=${BUILD}/etc
--localstatedir=${BUILD}/var. Also, when I did not use root to run
"make install", so it did not overwrite
/etc/dbus-1/system.d/connman.conf which was installed by Ubuntu
connman package. That could cause the problems.
(gdb) run CONNMAN_SUPPLICANT_DEBUG=1 -n -d -c /etc/connman/main.conf
plugins/wifi.c
Starting program: ./src/connmand CONNMAN_SUPPLICANT_DEBUG=1 -n -d -c
/etc/connman/main.conf plugins/wifi.c
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
connmand[25650]: Connection Manager version 1.26
connmand[25650]: ./src/dbus.c:__connman_dbus_init()
connmand[25650]: ./src/main.c:parse_config() parsing main.conf
connmand[25650]: ./src/inotify.c:__connman_inotify_init()
connmand[25650]: ./src/technology.c:__connman_technology_init()
connmand[25650]: ./src/storage.c:storage_load() Loading
./var/lib/connman/settings
connmand[25650]: ./src/storage.c:storage_load() Loading
./var/lib/connman/settings
connmand[25650]: ./src/notifier.c:__connman_notifier_init()
connmand[25650]: ./src/agent.c:__connman_agent_init()
connmand[25650]: ./src/service.c:__connman_service_init()
connmand[25650]: ./src/agent.c:connman_agent_driver_register()
Registering driver 0x55555582c2e0 name service
connmand[25650]: ./src/peer_service.c:__connman_peer_service_init()
connmand[25650]: ./src/peer.c:__connman_peer_init()
connmand[25650]: ./src/provider.c:__connman_provider_init()
connmand[25650]: ./src/notifier.c:connman_notifier_register() notifier
0x55555582c320 name provider
connmand[25650]: ./src/network.c:__connman_network_init()
connmand[25650]: ./src/config.c:__connman_config_init()
connmand[25650]: ./src/inotify.c:create_watch() Add directory watch
for ./var/lib/connman
connmand[25650]: ./src/config.c:read_configs()
connmand[25650]: ./src/device.c:__connman_device_init()
connmand[25650]: ./src/inet.c:__connman_inet_get_address_netmask() index 3
connmand[25650]: ./src/device.c:cleanup_devices() cleaning up wlp2s0 index 3
connmand[25650]: ./src/ippool.c:__connman_ippool_init()
connmand[25650]: ./src/iptables.c:__connman_iptables_init()
connmand[25650]: ./src/firewall.c:__connman_firewall_init()
connmand[25650]: ./src/iptables.c:iptables_init() filter
connmand[25650]: ./src/iptables.c:__connman_iptables_commit() filter
connmand[25650]: ./src/iptables.c:iptables_init() mangle
connmand[25650]: ./src/iptables.c:__connman_iptables_commit() mangle
connmand[25650]: ./src/iptables.c:iptables_init() nat
connmand[25650]: ./src/iptables.c:__connman_iptables_commit() nat
connmand[25650]: ./src/nat.c:__connman_nat_init()
connmand[25650]: ./src/notifier.c:connman_notifier_register() notifier
0x55555582c880 name nat
connmand[25650]: ./src/tethering.c:__connman_tethering_init()
connmand[25650]: ./src/counter.c:__connman_counter_init()
connmand[25650]: ./src/manager.c:__connman_manager_init()
connmand[25650]: ./src/notifier.c:connman_notifier_register() notifier
0x55555582c280 name manager
connmand[25650]: ./src/stats.c:__connman_stats_init()
connmand[25650]: ./src/clock.c:__connman_clock_init()
connmand[25650]: ./src/timezone.c:__connman_timezone_init()
connmand[25650]: ./src/timezone.c:__connman_timezone_lookup()
sysconfig zone (null)
connmand[25650]: ./src/timezone.c:__connman_timezone_lookup()
localtime zone Australia/Melbourne
connmand[25650]: ./src/storage.c:storage_load() Loading
./var/lib/connman/settings
connmand[25650]: ./src/resolver.c:__connman_resolver_init() dnsproxy 1
connmand[25650]: ./src/dnsproxy.c:__connman_dnsproxy_init()
connmand[25650]: ./src/dnsproxy.c:__connman_dnsproxy_add_listener() index 1
connmand[25650]: ./src/dnsproxy.c:get_listener() family 2 protocol 17 index 1
connmand[25650]: ./src/inet.c:__connman_inet_get_interface_address()
index 1 interface lo
connmand[25650]: ./src/dnsproxy.c:get_listener() family 10 protocol 17 index 1
connmand[25650]: ./src/inet.c:__connman_inet_get_interface_address()
index 1 interface lo
connmand[25650]: ./src/dnsproxy.c:get_listener() family 2 protocol 6 index 1
connmand[25650]: ./src/inet.c:__connman_inet_get_interface_address()
index 1 interface lo
connmand[25650]: ./src/dnsproxy.c:get_listener() family 10 protocol 6 index 1
connmand[25650]: ./src/inet.c:__connman_inet_get_interface_address()
index 1 interface lo
connmand[25650]: ./src/resolver.c:__connman_resolvfile_append() index
1 server ::1
connmand[25650]: ./src/resolver.c:__connman_resolvfile_append() index
1 server 127.0.0.1
connmand[25650]: ./src/notifier.c:connman_notifier_register() notifier
0x55555582c820 name dnsproxy
connmand[25650]: ./src/ipconfig.c:__connman_ipconfig_init()
connmand[25650]: ./src/rtnl.c:__connman_rtnl_init()
connmand[25650]: ./src/task.c:__connman_task_init()
connmand[25650]: ./src/proxy.c:__connman_proxy_init()
connmand[25650]: ./src/detect.c:__connman_detect_init()
connmand[25650]: ./src/rtnl.c:connman_rtnl_register() rtnl
0x55555582c380 name detect
connmand[25650]: ./src/session.c:__connman_session_init()
connmand[25650]: ./src/notifier.c:connman_notifier_register() notifier
0x55555582c540 name session
connmand[25650]: ./src/firewall.c:__connman_firewall_enable() mangle
INPUT -j CONNMARK --restore-mark
connmand[25650]: ./src/firewall.c:insert_managed_rule() table mangle
add managed chain for INPUT
connmand[25650]: ./src/iptables.c:__connman_iptables_new_chain() -t
mangle -N connman-INPUT
connmand[25650]: ./src/iptables.c:iptables_init() mangle
connmand[25650]: ./src/iptables.c:iptables_add_chain() table mangle
chain connman-INPUT
connmand[25650]: ./src/iptables.c:__connman_iptables_insert() -t
mangle -I INPUT -j connman-INPUT
connmand[25650]: ./src/iptables.c:iptables_insert_rule() table mangle
chain INPUT
connmand[25650]: ./src/iptables.c:__connman_iptables_append() -t
mangle -A connman-INPUT -j CONNMARK --restore-mark
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) backtrace
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff7669080 in xtables_find_target ()
from /usr/lib/x86_64-linux-gnu/libxtables.so.12
#2 0x00007ffff766949b in ?? () from /usr/lib/x86_64-linux-gnu/libxtables.so.12
#3 0x00007ffff7669152 in xtables_find_target ()
from /usr/lib/x86_64-linux-gnu/libxtables.so.12
#4 0x00005555555dc77a in prepare_target (
target_name=0x555555842a90 "CONNMARK", table=0x555555867840)
at ./src/iptables.c:1574
#5 parse_rule_spec (table=<optimised out>, ctx=0x555555867f80)
at ./src/iptables.c:1993
#6 0x00005555555dd1d8 in __connman_iptables_append (
table_name=table_name@entry=0x5555558419c0 "mangle",
chain=chain@entry=0x555555842c10 "connman-INPUT",
rule_spec=rule_spec@entry=0x555555862460 "-j CONNMARK --restore-mark")
at ./src/iptables.c:2196
#7 0x00005555555e7094 in insert_managed_rule (
rule_spec=0x555555862460 "-j CONNMARK --restore-mark",
chain_name=<optimised out>, table_name=0x5555558419c0 "mangle")
at ./src/firewall.c:180
#8 __connman_firewall_enable (ctx=ctx@entry=0x555555841820)
at ./src/firewall.c:336
---Type <return> to continue, or q <return> to quit---
#9 0x00005555555d4a68 in init_firewall ()
at ./src/session.c:219
#10 0x00005555555d6cd5 in init_firewall ()
at ./src/session.c:1740
#11 __connman_session_init ()
at ./src/session.c:1734
#12 0x0000555555572270 in main (argc=<optimised out>, argv=<optimised out>)
at ./src/main.c:670
Thank you Daniel
- jupiter
7:46 a.m.
Hi,
On Tue, Mar 19, 2019 at 09:44:25PM +1100, JH wrote:
connmand[25650]: ./src/iptables.c:__connman_iptables_append() -t
mangle -A connman-INPUT -j CONNMARK --restore-mark
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) backtrace
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff7669080 in xtables_find_target ()
from /usr/lib/x86_64-linux-gnu/libxtables.so.12
#2 0x00007ffff766949b in ?? () from /usr/lib/x86_64-linux-gnu/libxtables.so.12
#3 0x00007ffff7669152 in xtables_find_target ()
from /usr/lib/x86_64-linux-gnu/libxtables.so.12
#4 0x00005555555dc77a in prepare_target (
target_name=0x555555842a90 "CONNMARK", table=0x555555867840)
at ./src/iptables.c:1574
#5 parse_rule_spec (table=<optimised out>, ctx=0x555555867f80)
at ./src/iptables.c:1993
#6 0x00005555555dd1d8 in __connman_iptables_append (
table_name=table_name@entry=0x5555558419c0 "mangle",
chain=chain@entry=0x555555842c10 "connman-INPUT",
rule_spec=rule_spec@entry=0x555555862460 "-j CONNMARK --restore-mark")
at ./src/iptables.c:2196
#7 0x00005555555e7094 in insert_managed_rule (
rule_spec=0x555555862460 "-j CONNMARK --restore-mark",
chain_name=<optimised out>, table_name=0x5555558419c0 "mangle")
at ./src/firewall.c:180
#8 __connman_firewall_enable (ctx=ctx@entry=0x555555841820)
at ./src/firewall.c:336
---Type <return> to continue, or q <return> to quit---
#9 0x00005555555d4a68 in init_firewall ()
at ./src/session.c:219
#10 0x00005555555d6cd5 in init_firewall ()
at ./src/session.c:1740
#11 __connman_session_init ()
at ./src/session.c:1734
#12 0x0000555555572270 in main (argc=<optimised out>, argv=<optimised out>)
at ./src/main.c:670
iptables is a bit tricky, especially error handling. I am not 100%
convienced this code works right. But I don't want to touch it
either. Too many gray haires already. The last brave soul to touch it
was Jussi and I think he spend a lot of time hunting stuff.
If possible try to use the nftable backend instead of the iptables,
because there we have proper APIs to use.
That said, I see ConnMan was able to remove the old rules and fails
adding the CONNMARK rule to the mangle table. Is the CONNMARK and
mangle table available?
Thanks,
Daniel
8:31 a.m.
Hi Daniel and JH,
On 3/27/19 9:46 AM, Daniel Wagner wrote:
Hi,
On Tue, Mar 19, 2019 at 09:44:25PM +1100, JH wrote:
> connmand[25650]: ./src/iptables.c:__connman_iptables_append() -t
> mangle -A connman-INPUT -j CONNMARK --restore-mark
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000000000 in ?? ()
> (gdb) backtrace
> #0 0x0000000000000000 in ?? ()
> #1 0x00007ffff7669080 in xtables_find_target ()
> from /usr/lib/x86_64-linux-gnu/libxtables.so.12
> #2 0x00007ffff766949b in ?? () from /usr/lib/x86_64-linux-gnu/libxtables.so.12
> #3 0x00007ffff7669152 in xtables_find_target ()
> from /usr/lib/x86_64-linux-gnu/libxtables.so.12
> #4 0x00005555555dc77a in prepare_target (
> target_name=0x555555842a90 "CONNMARK", table=0x555555867840)
> at ./src/iptables.c:1574
> #5 parse_rule_spec (table=<optimised out>, ctx=0x555555867f80)
> at ./src/iptables.c:1993
> #6 0x00005555555dd1d8 in __connman_iptables_append (
> table_name=table_name@entry=0x5555558419c0 "mangle",
> chain=chain@entry=0x555555842c10 "connman-INPUT",
> rule_spec=rule_spec@entry=0x555555862460 "-j CONNMARK
--restore-mark")
> at ./src/iptables.c:2196
> #7 0x00005555555e7094 in insert_managed_rule (
> rule_spec=0x555555862460 "-j CONNMARK --restore-mark",
> chain_name=<optimised out>, table_name=0x5555558419c0 "mangle")
> at ./src/firewall.c:180
> #8 __connman_firewall_enable (ctx=ctx@entry=0x555555841820)
> at ./src/firewall.c:336
> ---Type <return> to continue, or q <return> to quit---
> #9 0x00005555555d4a68 in init_firewall ()
> at ./src/session.c:219
> #10 0x00005555555d6cd5 in init_firewall ()
> at ./src/session.c:1740
> #11 __connman_session_init ()
> at ./src/session.c:1734
> #12 0x0000555555572270 in main (argc=<optimised out>, argv=<optimised
out>)
> at ./src/main.c:670
iptables is a bit tricky, especially error handling. I am not 100%
convienced this code works right. But I don't want to touch it
either. Too many gray haires already. The last brave soul to touch it
was Jussi and I think he spend a lot of time hunting stuff.
If possible try to use the nftable backend instead of the iptables,
because there we have proper APIs to use.
That said, I see ConnMan was able to remove the old rules and fails
adding the CONNMARK rule to the mangle table. Is the CONNMARK and
mangle table available?
Thanks,
Daniel
To JH:
Which version of ConnMan are you using? According to the line numbers in
the GDB output the version you have does not include the improved error
handling for iptables, see [1],[2].
And I think these are requried to be enabled in kernel configs to use
CONNMARK target and match:
CONFIG_NETFILTER_XT_CONNMARK
CONFIG_NETFILTER_XT_TARGET_CONNMARK
CONFIG_NETFILTER_XT_MATCH_CONNMARK
CONFIG_NET_ACT_CONNMARK (not sure if this is needed)
I hope adding those to kernel configs helps with this issue.
To Daniel:
Yes, finding out these things with iptables takes time :) We have now
iptables 1.8.2 in use and as of now it seems that patch I mentioned in
[2] is no longer necessary. It applied only for iptables 1.6.1 (and most
likely, for 1.6.x).
Sincerely,
Jussi Laakkonen
[1]
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=b20...
[2]
https://git.kernel.org/pub/scm/network/connman/connman.git/tree/src/iptab...
[3] https://lists.01.org/pipermail/connman/2019-January/023146.html
11:11 a.m.
Hi Jussi,
I am sorry, I am still learning ConnMan. I original installed ConnMan
Ubuntu package v 1.35, it failed to run scan WiFi (posted to another
email), so I thought to try the latest git source, to compile it in
Ubuntu 18.04, but I did not run make install to set up configure files
in /etc, all /etc configure files could be linked to the Ubuntu
ConnMan 1.35. I would say it is my fault to have mixed versions, my
apology.
I am going to build ConnMan on Yocto and to run it on imx6 board, that
will have a clean environment. Will see if there is any issue or not.
Sorry about it.
Thank you.
- jupiter
On 3/27/19, Jussi Laakkonen <jussi.laakkonen(a)jolla.com> wrote:
Hi Daniel and JH,
On 3/27/19 9:46 AM, Daniel Wagner wrote:
> Hi,
>
> On Tue, Mar 19, 2019 at 09:44:25PM +1100, JH wrote:
>> connmand[25650]: ./src/iptables.c:__connman_iptables_append() -t
>> mangle -A connman-INPUT -j CONNMARK --restore-mark
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000000000000000 in ?? ()
>> (gdb) backtrace
>> #0 0x0000000000000000 in ?? ()
>> #1 0x00007ffff7669080 in xtables_find_target ()
>> from /usr/lib/x86_64-linux-gnu/libxtables.so.12
>> #2 0x00007ffff766949b in ?? () from
>> /usr/lib/x86_64-linux-gnu/libxtables.so.12
>> #3 0x00007ffff7669152 in xtables_find_target ()
>> from /usr/lib/x86_64-linux-gnu/libxtables.so.12
>> #4 0x00005555555dc77a in prepare_target (
>> target_name=0x555555842a90 "CONNMARK", table=0x555555867840)
>> at ./src/iptables.c:1574
>> #5 parse_rule_spec (table=<optimised out>, ctx=0x555555867f80)
>> at ./src/iptables.c:1993
>> #6 0x00005555555dd1d8 in __connman_iptables_append (
>> table_name=table_name@entry=0x5555558419c0 "mangle",
>> chain=chain@entry=0x555555842c10 "connman-INPUT",
>> rule_spec=rule_spec@entry=0x555555862460 "-j CONNMARK
>> --restore-mark")
>> at ./src/iptables.c:2196
>> #7 0x00005555555e7094 in insert_managed_rule (
>> rule_spec=0x555555862460 "-j CONNMARK --restore-mark",
>> chain_name=<optimised out>, table_name=0x5555558419c0
"mangle")
>> at ./src/firewall.c:180
>> #8 __connman_firewall_enable (ctx=ctx@entry=0x555555841820)
>> at ./src/firewall.c:336
>> ---Type <return> to continue, or q <return> to quit---
>> #9 0x00005555555d4a68 in init_firewall ()
>> at ./src/session.c:219
>> #10 0x00005555555d6cd5 in init_firewall ()
>> at ./src/session.c:1740
>> #11 __connman_session_init ()
>> at ./src/session.c:1734
>> #12 0x0000555555572270 in main (argc=<optimised out>, argv=<optimised
>> out>)
>> at ./src/main.c:670
>
>
> iptables is a bit tricky, especially error handling. I am not 100%
> convienced this code works right. But I don't want to touch it
> either. Too many gray haires already. The last brave soul to touch it
> was Jussi and I think he spend a lot of time hunting stuff.
>
> If possible try to use the nftable backend instead of the iptables,
> because there we have proper APIs to use.
>
> That said, I see ConnMan was able to remove the old rules and fails
> adding the CONNMARK rule to the mangle table. Is the CONNMARK and
> mangle table available?
>
> Thanks,
> Daniel
To JH:
Which version of ConnMan are you using? According to the line numbers in
the GDB output the version you have does not include the improved error
handling for iptables, see [1],[2].
And I think these are requried to be enabled in kernel configs to use
CONNMARK target and match:
CONFIG_NETFILTER_XT_CONNMARK
CONFIG_NETFILTER_XT_TARGET_CONNMARK
CONFIG_NETFILTER_XT_MATCH_CONNMARK
CONFIG_NET_ACT_CONNMARK (not sure if this is needed)
I hope adding those to kernel configs helps with this issue.
To Daniel:
Yes, finding out these things with iptables takes time :) We have now
iptables 1.8.2 in use and as of now it seems that patch I mentioned in
[2] is no longer necessary. It applied only for iptables 1.6.1 (and most
likely, for 1.6.x).
Sincerely,
Jussi Laakkonen
[1]
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=b20...
[2]
https://git.kernel.org/pub/scm/network/connman/connman.git/tree/src/iptab...
[3] https://lists.01.org/pipermail/connman/2019-January/023146.html
7:14 p.m.
Hi,
On 3/27/19 12:11 PM, JH wrote:
Hi Jussi,
I am sorry, I am still learning ConnMan. I original installed ConnMan
Ubuntu package v 1.35, it failed to run scan WiFi (posted to another
email), so I thought to try the latest git source, to compile it in
Ubuntu 18.04, but I did not run make install to set up configure files
in /etc, all /etc configure files could be linked to the Ubuntu
ConnMan 1.35. I would say it is my fault to have mixed versions, my
apology.
You can run ConnMan in the source directory without installing
everything. Just run the bootstrap-configure script and call make after
that. Then install D-Bus configuration files by copying i to
/etc/dbus-1/system.d/connman-dbus.conf
After that you can do 'sudo ./src/connmand -n -d'
I am going to build ConnMan on Yocto and to run it on imx6 board,
that
will have a clean environment. Will see if there is any issue or not.
Yocto is probably using an older version of ConnMan. You might want to
update the corresponding recipe.
Thanks,
Daniel
7:24 p.m.
Hi Jussi,
On 3/27/19 9:31 AM, Jussi Laakkonen wrote:
Yes, finding out these things with iptables takes time :) We have now
iptables 1.8.2 in use and as of now it seems that patch I mentioned in
[2] is no longer necessary. It applied only for iptables 1.6.1 (and most
likely, for 1.6.x).
Thanks for letting us know!
Maybe we should update the dependency to iptables 1.8.2 in this case.
Currently, we ask for 1.4.11 which pretty old release from 26.05.2011.
1.4.21 released on 22.11.2013
1.6.1 released on 02.02.2018
1.8.0 released on 07.07.2018
1.8.1 released on 23.10.2018
1.8.2 releases on 13.11.2018
Aehm, not sure what to do though... 5 years nothing end then a lot of
updates. I don't think many distros have picked up the latest version
yet. My Fedora 29 ships 1.8.0.
Thanks,
Daniel
10:07 a.m.
Hi Daniel
On 3/27/19 9:24 PM, Daniel Wagner wrote:
Hi Jussi,
On 3/27/19 9:31 AM, Jussi Laakkonen wrote:
> Yes, finding out these things with iptables takes time :) We have now
> iptables 1.8.2 in use and as of now it seems that patch I mentioned in
> [2] is no longer necessary. It applied only for iptables 1.6.1 (and
> most likely, for 1.6.x).
Thanks for letting us know!
Maybe we should update the dependency to iptables 1.8.2 in this case.
Currently, we ask for 1.4.11 which pretty old release from 26.05.2011.
1.4.21 released on 22.11.2013
1.6.1 released on 02.02.2018
1.8.0 released on 07.07.2018
1.8.1 released on 23.10.2018
1.8.2 releases on 13.11.2018
Aehm, not sure what to do though... 5 years nothing end then a lot of
updates. I don't think many distros have picked up the latest version
yet. My Fedora 29 ships 1.8.0.
Well, upping the requirement is quite tricky as we also noticed.
Iptables 1.8.2 (and I'm guessing rest of the 1.8.x) will require newer
kernel headers that are available with 4.2.8. Unless the system is
running fairly up-to-date kernel it requires another patch for the
kernel headers.
My Debian, for example, seems to use 1.6.1 still, which we had also used
with older 3.x kernels without any problems. Except when we started to
use iptables for IPv6 as well via ConnMan (I should make these firewall
changes into a separate plugin and try to upstream it someday) we needed
to patch iptables.
Upping the version requirement would anyways require some patching on
systems running older versions of kernel or iptables. Depending on the
use of course :).
- Jussi
6:15 a.m.
Good Morning Jussi,
On 3/28/19 11:07 AM, Jussi Laakkonen wrote:
On 3/27/19 9:24 PM, Daniel Wagner wrote:
> 1.4.21 released on 22.11.2013
> 1.6.1 released on 02.02.2018
> 1.8.0 released on 07.07.2018
> 1.8.1 released on 23.10.2018
> 1.8.2 releases on 13.11.2018
Well, upping the requirement is quite tricky as we also noticed.
Iptables 1.8.2 (and I'm guessing rest of the 1.8.x) will require newer
kernel headers that are available with 4.2.8. Unless the system is
running fairly up-to-date kernel it requires another patch for the
kernel headers.
Good point.
My Debian, for example, seems to use 1.6.1 still, which we had also
used
with older 3.x kernels without any problems. Except when we started to
use iptables for IPv6 as well via ConnMan (I should make these firewall
changes into a separate plugin and try to upstream it someday) we needed
to patch iptables.
Upping the version requirement would anyways require some patching on
systems running older versions of kernel or iptables. Depending on the
use of course :).
Maybe we should just add a warning/recommendation instead. 'Saying you
are using a dated iptables which might not work correctly.' So people
can check if they are happy with what they get.
Thanks,
Daniel
1235
days inactive
1248
days old
10 comments
3 participants
participants (3)
-
Daniel Wagner -
JH -
Jussi Laakkonen