[j-nsp] "ping: sendto: Operation not permitted" in LAN

[Stefan Fouant]

Hi Saku,

I think we are simply getting the wires crossed.  Your original email stated "Trio appears to change this, in inet6 simply doing 'match port X' without 'match next-header tcp|udp' correctly finds port X, regardless of its position in the frame (you can move the UDP/TCP port position via extension headers)."  We were originally talking about TCP options, and somehow the topic got switched to the behavior with ports. I was responding that for port, current incarnations do the same thing (vs. Trio).

I see your point however with regards to other behavior in Trio and agree it's better.

Thanks,

Stefan Fouant
JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant

Sent from my iPad

On Aug 19, 2011, at 4:29 AM, Saku Ytti <saku at ytti.fi> wrote:

> On (2011-08-18 21:23 -0400), Stefan Fouant wrote:
> 
>> Trio has nothing to do with this - the behavior when matching on a
>> port is completely different than using the bit-field match
>> operators.  Even without Trio, if you specify a match on a port
>> without protocol, it will look in the appropriate locations
>> depending on whether the traffic is TCP or UDP.  That is not the
>> case with bit-field match operators.
>> 
>> See http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-policy/policy-firewall-filter-how-to-specify-match-conditions.html#jd0e29000
> 
> Thanks for clearing that up. However if 'port' assumes implied udp/tcp (instead
> of just finding port values in predefined offset, regardless of protocol) why
> doesn't 'tcp-established' assume implied tcp? Is there any useful application
> behind this inconsistency?
> 
> Also do you have access internally to information which you are able to share,
> when would JunOS CLI get 'match protocol udp|tcp|icmp' for ipv6? So users
> could, in existance of extension headers still match for L4 protocol?
> 
> Thanks again,
> -- 
>  ++ytti
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp