I would like to establish a firewall on a QNX box. This firewall must
only allow IP addresses 192.168.11.X on port 5085 (TCP only).
The help documentation refer to lsm-ipfilter.so which is nowhere to be
seen on my computer. Why?
I eventually installed ipfilter V3.4.6 from the web but which uses
nfm-ipfilter.so (already different from the documentation).
My rules file is:
block in all
pass in quick on en0 proto tcp from 192.168.11.0/24 to 192.168.11.0/24
port = 5085
pass out quick on en0 proto tcp from 192.168.11.0/24 port = 5085 to
192.168.11.0/24
I have activated the filter and performed ipfstat commands:
mount -T io-net -o file=/truvelo/diskimg/combi/etc/ipf.conf
/lib/dll/nfm-ipfilter.so
IP Filter: v3.4.6 initialized. Default = pass all, Logging = enabled
IP Filter: v3.4.6
ipfstat -i
block in from any to any
pass in quick on en0 proto tcp from 192.168.11.0/24 to 192.168.11.0/24
port = 5085
ipfstat -o
pass out quick on en0 proto tcp from 192.168.11.0/24 port = 5085 to
192.168.11.0/24
From another computer I then establish a telnet session (which is
supposed to fail) but the session was established.
nestat and ipfstat provide the following info:
netstat
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 192.168.11.67.telnet 192.168.11.66.1227
ESTABLISHED
I would like to establish a firewall on a QNX box. This firewall must
only allow IP addresses 192.168.11.X on port 5085 (TCP only).
The help documentation refer to lsm-ipfilter.so which is nowhere to be
seen on my computer. Why?
I eventually installed ipfilter V3.4.6 from the web but which uses
nfm-ipfilter.so (already different from the documentation).
My rules file is:
block in all
pass in quick on en0 proto tcp from 192.168.11.0/24 to 192.168.11.0/24
port = 5085
pass out quick on en0 proto tcp from 192.168.11.0/24 port = 5085 to
192.168.11.0/24
lsm-ipfilter.so is included with the Extended Networking TDK.
I tried out the third party nfm-ipfilter and was able to block telnet
from a specific host with the following in my rules file:
block in on en0 proto tcp/udp from to any port = 24
On Fri, 18 Mar 2005 12:16:53 -0500, Joe Mammone <hw@qnx.com> wrote:
lsm-ipfilter.so is included with the Extended Networking TDK.
I tried out the third party nfm-ipfilter and was able to block telnet
from a specific host with the following in my rules file:
block in on en0 proto tcp/udp from to any port = 24
Joe
Francois is a customer of Systems 104 in South Africa.
Can you please show how you invoke ipfilter on 6.3.0?
(mount command as well as output from ipfilter
when signing on)
Also what is your network setup?
On Fri, 18 Mar 2005 12:16:53 -0500, Joe Mammone <> hw@qnx.com> > wrote:
lsm-ipfilter.so is included with the Extended Networking TDK.
I tried out the third party nfm-ipfilter and was able to block telnet
from a specific host with the following in my rules file:
block in on en0 proto tcp/udp from to any port = 24
Joe
Francois is a customer of Systems 104 in South Africa.
Can you please show how you invoke ipfilter on 6.3.0?
(mount command as well as output from ipfilter
when signing on)
Also what is your network setup?
On Fri, 18 Mar 2005 12:16:53 -0500, Joe Mammone <> hw@qnx.com> > wrote:
lsm-ipfilter.so is included with the Extended Networking TDK.
I tried out the third party nfm-ipfilter and was able to block
telnet from a specific host with the following in my rules file:
block in on en0 proto tcp/udp from to any port = 24
Joe
Francois is a customer of Systems 104 in South Africa.
Can you please show how you invoke ipfilter on 6.3.0?
(mount command as well as output from ipfilter
when signing on)
Also what is your network setup?
Thanks in advance
We are not going to get any answers here, are we?
I was using a 6.2 system for my initial tests.
I tried this out an 6.3.0, and I am seeing the same behavior as you
described. Looks like ipfilter may need to be updated to work with
6.3.0. I believe the source is available on the third party CD.
On Thu, 31 Mar 2005 09:28:33 -0500, Joe Mammone <hw@qnx.com> wrote:
I was using a 6.2 system for my initial tests.
I tried this out an 6.3.0, and I am seeing the same behavior as you
described. Looks like ipfilter may need to be updated to work with
6.3.0. I believe the source is available on the third party CD.
THe required headers for this is now only available in
the extended networking TDK.
Purchasing this would not be an option.
Customer is unhappy about having to
buy additional libraries in order to run & compile
something that was already included in 6.2.,
ie already bought and paid for.
Would you be willing to port it and make at least the
binaries available?
On Thu, 31 Mar 2005 09:28:33 -0500, Joe Mammone <> hw@qnx.com> > wrote:
I was using a 6.2 system for my initial tests.
I tried this out an 6.3.0, and I am seeing the same behavior as you
described. Looks like ipfilter may need to be updated to work with
6.3.0. I believe the source is available on the third party CD.
THe required headers for this is now only available in
the extended networking TDK.
Purchasing this would not be an option.
This is one of the disappointing trends that QSS has been on, 6.3.0 actually
removes more components than it updates from 6.2.1, and this applies to the
commercial SE and PE versions as well. It is especially frustrating and
annoying when features like ipfilter that were free for 6.2.1 (and not even
officially from QSS) get officially incorporated into 6.3.0 but only as a
TDK. One of the most expensive ones too.
The big problem with ALL the TDKs is that QSS has completely screwed up on
the marketing and distribution. You can only buy them on a per-project basis,
there is NO provision for runtimes for those customers that might need them
for smaller volume projects. There is also no official way to eval them to see
if you need them, so you have to commit to the large TDK fees just to eval
a TDK.
Don’t even get me started on the fact that ipfilter does not belong with the
rest of the IPv6 stuff. Two different worlds, which QSS’s marketing completely
failed to realize. Sure, go ahead and include the IPv6 enabled version of
ipfilter with the TDK, but make the IPv4 one available via 3rd party at least.
I was using a 6.2 system for my initial tests.
I tried this out an 6.3.0, and I am seeing the same behavior as you
described. Looks like ipfilter may need to be updated to work with
6.3.0. I believe the source is available on the third party CD.
THe required headers for this is now only available in
the extended networking TDK.
Purchasing this would not be an option.
This is one of the disappointing trends that QSS has been on, 6.3.0
actually
removes more components than it updates from 6.2.1, and this applies to
the
commercial SE and PE versions as well. It is especially frustrating and
annoying when features like ipfilter that were free for 6.2.1 (and not
even
officially from QSS) get officially incorporated into 6.3.0 but only as a
TDK. One of the most expensive ones too.
The big problem with ALL the TDKs is that QSS has completely screwed up
on
the marketing and distribution. You can only buy them on a per-project
basis,
there is NO provision for runtimes for those customers that might need
them
for smaller volume projects.
It maybe a problem for you, but isn’t QSS task to make money If they feel
they have something that some people are willing to pay extra money for, why
give it for free? Isn’t what business is about, squeezing all the money you
can from your customer. Of course if you squeeze to hard, that’s not good Not an easy line to ride. QSS is becoming (I feel) more and more like
WindRiver in the way they do business, that’s probably good for them since
WindRiver is worth a LOTS of money, so they must have done something right.
I’m hoping it’s just an overshoot when deciding how to divide up the various parts under the new scheme. If not, then the NC community will die for good.
I’m hoping it’s just an overshoot when deciding how to divide up the
various parts under the new scheme. If not, then the NC community will
die for good.
I’m hoping it’s just an overshoot when deciding how to divide up the
various parts under the new scheme. If not, then the NC community will
die for good.
It’s already dead if you ask me.
Evan
Opps, is this not advocacy?!
\
I am fairly new in the QNX environment and is therefore not aware at all
of the politics regarding QNX and its community.
I was looking for an embedded OS because I require a reliable
multi-tasksing OS, file system and networking capabilities. QNX offered
all this plus the support through Alex.
I know enough about hardware development and writing software to
communicate with the hardware. But I know nothing about writing
networking software and why should I? QNX offers all that.
Until now, that is. Now suddenly I find myself upgrading from 6.2 (from
which I started from) to 6.3 (because I wanted improved USB support) and
I must now try to make ipfilter work. The 3rd party version does not
work on 6.3. The source does not want to compile on 6.3 because there is
a missing header (net/if_vp.h to be precise). I doubt it very much, if I
manage to obtain this header file, that it will work.
I tried the ipfilter@coombs.anu.edu.au mail list. Got no answer from
them on the header file. Perhaps they could not be bothered with QNX.
Alex recons it is in the TDK. Is it in the TDK? I will be grateful if
somebody could answer this question.
I wonder if anyone knows how much are the TDKs in general? Hundreds or
thousands or tens of thousands? I asked my representative at one point,
but I got no answer. Does any one know?
Not an easy line to ride. QSS is becoming (I feel) more and more like