> i.e. in your rule:
> > rdr pass on $ext_if inet proto udp from any to 192.168.1.1 port 60000 -> 169
> .254.3.255 port 50000
> 
> 169.254.3.255 is technically not a broadcast because it is out of a /16, so 
> 169.254.255.255 would be its broadcast.


Hi Patrik :
I have forced to configure the IP to 169.254.3.1/24, see the result of ifconfig
# ifconfig tsec1
tsec1: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST>  mtu 1500
        capabilities rx=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
        capabilities tx=0
        enabled=0
        address: 00:20:ce:e0:00:31
        media: Ethernet none
        inet 169.254.1.15 netmask 0xffffff00 broadcast 169.254.1.255

So I guess the broadcast 169.254.1.255

as I understand(may be mistake), the broadcast address is depend on how you subneting, however, if use a old protocol, 
RIPv1 for example, it will use the default netmask, but if use the later version, should be fine. 

Hello,

Is it your goal to make the link-local address (169.254) to talk to
192.168?

The "autoip" module (lsm-autoip.so) is designed to auto assign
link-local and make sure a link-local address would be able to talk to a
local LAN address. (As per Link-Local required)

Just thought I should mention this.

-xtang


> -----Original Message-----
> From: Ji Dong [mailto:community-noreply@qnx.com]
> Sent: September 18, 2009 3:56 AM
> To: technology-networking
> Subject: Re: Packet filter questions
> 
> > Hi Ji,
> >
> >  From a high level, AFAIU, the translated UDP packets will be
delivered
> > to the stack and processed as incoming again.
> >
> > If you wanted the redirected packets to be sent out on a wire, then
you
> > should make sure your IP forwarding flag is on. If forwarding is on,
> > then I'd expect the packet to be attempted to be delivered locally
(i.e.
> > see if destination matches an address assigned to the interface) or
be
> > forwarded. If forwarding is off, then I'd expect the packet to be
> > attempted locally only.
> >
> > However, you're translating to a destination address under the
prefix
> > 169.254.0.0/16 which is reserved as link-local, see
> >
http://iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
> > Link-local packets should stay link-local, so setting up forwarding
of
> > that isn't really ok.
> >
> > A node that receives the redirected UDP packet will try to match it
> > against its open UDP sockets. If there are no matching sockets, then
you
> > should expect to see the the port unreachable ICMP error that you
are
> > seeing.
> >
> > I suggest you check the UDP stats and ICMP stats to see what is
> > happening in the local stack. And (if forwarding was what you
wanted)
> > that you check forwarding stats to see if there are any unroutable
> > packets dropped. And if you did expect a matching socket to receive
the
> > packet, then check what opened sockets you have using netstat.
> >
> > Hope this helps!
> > /P
> 
> 
> Hi Patrik:
> 
> Thanks for your quick respones.
> Our network will be for local use only, it will never expose to
internet,
> and our device have 2 Ethernet port, so my plan is:
> 1.Use 192.168.xxx.xxx/24 as our routeable network.
> 2. Use 169.254.0.0/16  as local net
> I understand for link-local address, as per iana, there are a lot of
> limitation for that, for example, it is not routeable, however, I find
it
> seems not comply to QNX implmentation.
> I have do a small test, I enable RIP2 for both port, and I can see the
> interesting thing is the routing table is updating on the other side,
and
> I can send a package form one port and route though the other port to
go
> to another device.
> Then I guess these sort of address is depend on configuration of
routed
> for example. without these special configuration, the TCP/IP stack
will
> treated as no more than a normal IP addresses.
> For this feature, I possiblely can rely on some comercial router to
stop
> our local net spread out our device group.(not sure if this is a
correct
> way to do it, however, it looks work in our project)
> 
> Because I have enable RIP2, and it can route, so I am quite sure, the
> ipforward is enabled
> 
> BTW: can you suggest how can I check  forwarding stats? I have use
pfctrl
> in a vebose mode, but there is no such forwarding stats come on my
screen.
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 
> Technology
> http://community.qnx.com/sf/go/post38246

> Our network will be for local use only, it will never expose to internet, 
It is not about whether you expose it to the Internet or not. (it'll 
just get dropped anyways).

Link-local does not mean "local to your site". It means it is intended 
to stay on the link - i.e. not leave the ethernet segment. Just like 
IPv6 link-local addresses work (fe80::/10).
> and our device have 2 Ethernet port, so my plan is:
> 1.Use 192.168.xxx.xxx/24 as our routeable network. 
> 2. Use 169.254.0.0/16  as local net
> I understand for link-local address, as per iana, there are a lot of limitation for that, for example, it is not 
routeable, however, I find it seems not comply to QNX implmentation. 
> I have do a small test, I enable RIP2 for both port, and I can see the interesting thing is the routing table is 
updating on the other side, and I can send a package form one port and route though the other port to go to another 
device.
>   
There's nothing wrong with the QNX implementation. If you configure 
io-pkt to route 169.254.0.0/16 somewhere, then it will obey that 
configuration. Unlike IPv6 link-local addresses, IPv4 link-locals did 
not exist in the original specs and were added later so there is no 
requirement on stacks to treat them specially.

I'm saying what you're doing is a misconfiguration unless you have some 
very specific (and peculiar) requirements :-) I can't comment on it 
further without knowing your particular requirements but it sounds like 
you should be using private addressing.

> Then I guess these sort of address is depend on configuration of routed for example. without these special 
configuration, the TCP/IP stack will treated as no more than a normal IP addresses.
>   
Yes, that's the design intent.

> For this feature, I possiblely can rely on some comercial router to stop our local net spread out our device group.
(not sure if this is a correct way to do it, however, it looks work in our project)
>
> Because I have enable RIP2, and it can route, so I am quite sure, the ipforward is enabled
>
> BTW: can you suggest how can I check  forwarding stats? I have use pfctrl in a vebose mode, but there is no such 
forwarding stats come on my screen.
>   
Please see the documentation for the netstat command (e.g. netstat -p 
ip) here:
http://www.qnx.com/developers/docs/6.4.1/neutrino/utilities/n/netstat.html

/P