headers
Pavel Cahyna | 3 May 2007 23:25
Picon

Re: wpa_supplicant endian issue

On Thu, Apr 26, 2007 at 12:26:43PM -0400, Sean Boudreau wrote:
> On Thu, Apr 26, 2007 at 09:16:07AM -0700, Sam Leffler wrote:
> > Sam Leffler wrote:
> > > Sean Boudreau wrote:
> > >> Hi:
> > >>
> > >> I was unable to get authenticated on a big endian
> > >> machine.  Turns out the receive sequence counter
> > >> is little endian on the wire.  Are there any objections
> > >> to the following before I commit?
> > >>
> > >> Regards,
> > >>
> > >> -seanb
> > >>
> > >>
> > >> Index: driver_netbsd.c
> > >> ===================================================================
> > >> RCS file: /cvsroot/src/usr.sbin/wpa/wpa_supplicant/driver_netbsd.c,v
> > >> retrieving revision 1.1
> > >> diff -c -r1.1 driver_netbsd.c
> > >> *** driver_netbsd.c	1 Oct 2005 18:50:12 -0000	1.1
> > >> --- driver_netbsd.c	25 Apr 2007 13:04:55 -0000
> > >> ***************
> > >> *** 341,346 ****
> > >> --- 341,347 ----
> > >>   		wk.ik_keyix = IEEE80211_KEYIX_NONE;
> > >>   	wk.ik_keylen = key_len;
> > >>   	memcpy(&wk.ik_keyrsc, seq, seq_len);
> > >> + 	wk.ik_keyrsc = le64toh(wk.ik_keyrsc);
(Continue reading)

Permalink | Reply | 1 comment |
headers
6bone | 4 May 2007 12:30
Picon

Re: page fault in fr_checkicmp6matchingstate

Hello,

now the complete trace from the last crash:

kernel: page fault trap, code=0
Stopped at netbsd:fr_checkicmp6matchingstate+0x95: movw 0x4(%edi),%bx
db{0}> trace
fr_checkicmp6matchingstate(cbadaa48,0,28,cbaddaa48,8) at 
netbsd:fr_checkicmp6matchingstate+0x95
fr_stlookup(cbadda48,c2affff8,cbadaa10,0,cbadda48) at 
netbsd:fr_stlookup+0x2c4
fr_checkstate(cbadaa48,cbadaa44,cbadaa48,1,6) at 
netbsd:fr_checkstate+0x21f
fr_check(c2afffd0,28,c1bc104c,1,cbadab50) at netbsd:fr_check+0x4bd
fr_check_wrapper6(0,cbadab50,c1bc104c,2,c1bc104c) at 
netbsd:fr_check_wrapper6+0x23
pfil_run_hooks(c091b120,cbadabdc,c1bc104c,2,6bd50e60) at 
netbsd:pfil_run_hooks+0x6e
ip6_output(c2afff00,0,cbadac98,4,0) at netbsd:ip6_output+0x891
icmp6_reflect(c2afff00,28,1,8000000,cb77f816) at 
netbsd:icmp6_reflect+0x287
icmp6_error(c2affb00,2,0,500,c2afff00) at netbsd:icmp6_error+0x1b8
ip6_forward(c2accf00,0,c1bc104c,1,c1ba1120) at netbsd:ip6_forward+0x47d
ip6_input(c2accf00,7,cbadaf50,202,42) at netbsd:ip6_input+0x495
ip6intr(cbad0010,30,10,80010010,cbad7000 at netbsd:ip6intr+0x86
DDB lost frame for netbsd:Xsoftnet+0x56, trying 0xcbadaf58
Xsoftnet() at netbsd:Xsoftnet+0x56

You can download the screenshot from http://139.18.25.35/dump.jpg
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sean Boudreau | 4 May 2007 17:47

Re: wpa_supplicant endian issue

On Thu, May 03, 2007 at 11:25:37PM +0200, Pavel Cahyna wrote:

> Does this need a pull-up to the netbsd-4 branch?
> 
> Pavel

Sure.

-seanb
Permalink | Reply | 0 comments |
headers
Pavel Cahyna | 6 May 2007 14:54
Picon

Re: page fault in fr_checkicmp6matchingstate

On Fri, May 04, 2007 at 12:30:36PM +0200, 6bone <at> 6bone.informatik.uni-leipzig.de wrote:
> Hello,
> 
> now the complete trace from the last crash:

Do you have netbsd.gdb?

Pavel
Permalink | Reply | 0 comments |
headers
David Young | 6 May 2007 21:23
Picon
Favicon

Re: gre encap destination = point-to-point destination

On Sun, Nov 05, 2006 at 02:23:11PM +0100, Gert Doering wrote:
> Besides that: David, could you go into a bit more details about your
> great GRE rewrite?  I don't claim to understand all the kernel IP 
> routing / interface details - but I'm always interested in IPv6-related
> work, and GRE tunnels are useful :-)

I am about ready to work on this.  Let me tell you what I have in mind.

Right now, gre(4) adds/removes encapsulating IP headers, it hooks
into protocol switches in order to "catch" packets sent to its IP
protocol numbers of interest, and it demultiplexes received packets.
We can do all of that with a socket.  I will make gre use one.

A socket hides such details of its implementation from gre(4) as the
encapsulation type (IPv4, IPv6, UDP), the protocol hooks, and the
demultiplexing, so I can simplify gre and remove its "hooks" from the
IPv4 stack.  Without adding new "hooks," I can add an IPv6 encapsulation
to gre---bonus!

Ok, so there is a catch: a raw IPv4 socket is not suitable for my purpose.
It is not "symmetrical": it removes the IPv4 header from received packets,
but it does not add the IPv4 header to transmitted packets.  No other
IPv4 socket is suitable.  I need to either add an option to the raw IPv4
socket that makes it supply the IPv4 header, or I need to introduce new,
symmetrical socket types---socket(PF_INET, SOCK_DGRAM, IPPROTO_GRE)?
I am inclined to add an option to the raw socket.

After I convert gre to use sockets, I will add to it the capability to
tunnel ethernet frames.
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Young | 6 May 2007 21:46
Picon
Favicon

Re: gre encap destination = point-to-point destination

On Sun, May 06, 2007 at 02:23:29PM -0500, David Young wrote:
> Ok, so there is a catch: a raw IPv4 socket is not suitable for my purpose.
> It is not "symmetrical": it removes the IPv4 header from received packets,
> but it does not add the IPv4 header to transmitted packets.

I misspoke.  The received packets, not the transmitted packets, contain
an IP header.

Dave

--

-- 
David Young             OJC Technologies
dyoung <at> ojctech.com      Urbana, IL * (217) 278-3933
Permalink | Reply | 0 comments |
headers
6bone | 7 May 2007 06:58
Picon

Re: page fault in fr_checkicmp6matchingstate

hello,

I am sorry, but I do not have a valid netbsd.gdb.
I will build a new kernel and resend all data at the next crash.

thank you for your efforts
Uwe
Permalink | Reply | 0 comments |
headers
David Young | 7 May 2007 08:01
Picon
Favicon

stopping PF NAT state from "floating" ?

I am using PF for NAT.  I would like to stop NAT states from floating
between interfaces.  I have searched all day for a solution, but I have
not found one.  Does anyone know how?

Details:

I have this translation rule on the ethernet admsw0,

nat on admsw0 inet from <cuwin> to ! <cuwin> -> 192.168.1.4 port 10000:20000

I have noticed that the translation states will "float" between admsw0 and
ath0.  That is, if the routes change so that a flow that passes through
admsw0 passes through ath0, instead, then the address translations from
admsw0 continue to apply to the flow on ath0.  I can see why that might
be desirable in some cases, but it is bad for my application.

Here is the NAT state:

self udp 10.0.246.46:65533 -> 192.168.1.4:14690 -> a.b.c.d:2524       SINGLE:NO_TRAFFIC
self udp 10.0.246.46:65531 -> 192.168.1.4:13794 -> a.b.c.d:2525       SINGLE:NO_TRAFFIC

I see those translations applied to traffic going out ath0 after the route
to a.b.c.d moves from admsw0 to ath0.  As I say, that's not what I desire.

I thought that 'set state-policy if-bound' would help, but I have found
out in other experiments that it will not.  I believe I understand why not
after reading the PF sources, especially sys/dist/pf/sbin/pfctl/parse.y
and sys/dist/pf/net/pf.c.

Is there a way to stop NAT states from "floating" that I have missed?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Daniel Carosone | 7 May 2007 08:40
Picon

Re: stopping PF NAT state from "floating" ?

On Mon, May 07, 2007 at 01:01:47AM -0500, David Young wrote:
> I am using PF for NAT.  I would like to stop NAT states from floating
> between interfaces.  I have searched all day for a solution, but I have
> not found one.  Does anyone know how?

First question, if this is a "flow" where changing the IP addressing
within the "flow" when the routing changes doesn't break the
application, is whether you need a persistent NAT state at all.

Ie, if they're udp packets that should be hidden behind the relevant
exit interface address, and each packet is essentially independent
from those that proceed and follow it, why do you need to keep much
state at all?  You could play with really short timeouts for these NAT
states.  Are there replies to these packets that must come back?
Maybe you want to kill the state immediately on that reply, and let
the next request create a new one-time state?

Alternately, could you try tagging these flows, and when the route
changes, flush all states with the tag.  I don't know pf enough to say
whether there's a way to do that.

> I can see why that might
> be desirable in some cases, but it is bad for my application.

Sure, for anything like a tcp connection, for example. As above, to
me, this seems that you don't want/need to be keeping state for these
packets.

> I thought that 'set state-policy if-bound' would help, but I have found
> out in other experiments that it will not.  I believe I understand why not
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Young | 7 May 2007 09:50
Picon
Favicon

Re: stopping PF NAT state from "floating" ?

On Mon, May 07, 2007 at 04:40:40PM +1000, Daniel Carosone wrote:
> On Mon, May 07, 2007 at 01:01:47AM -0500, David Young wrote:
> > I am using PF for NAT.  I would like to stop NAT states from floating
> > between interfaces.  I have searched all day for a solution, but I have
> > not found one.  Does anyone know how?
> 
> First question, if this is a "flow" where changing the IP addressing
> within the "flow" when the routing changes doesn't break the
> application, is whether you need a persistent NAT state at all.

For the application to work, the state does have to persist.  What is
more important is the network, I think:

                                 Router A                Router B
                             |  +---------+             +---------+
   __     ___                |  |         |             |         |  a.b.c.d
  /  \___/   \               |--|admsw0   |             |     sip0|--+
  \ the (ugly)| +----------+ |  |         |             |    (NAT)|  |
  /  Internet |-|NAT router|-|  |     ath0|-- 10.0/16 --|ath0     |  |
  |     _    /  +----------+ |  |_________|             |_________|  |
   \___/ \__/                |                                       |
           |                 |                                       |
           |           192.168.1/24                                  |
           |                                                         |
           +---------------------------------------------------------+

a.b.c.d is a globally routable IP address.  Router B NATs 10/8 to a.b.c.d.
Router B neither knows a route to 192.168.1/24, nor should it.  So there
is no sense in translating an address in 10.0/16 to 192.168.1.4 before
sending it out ath0 on Router A.  Nevertheless, that is what is happening.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane