-----BEGIN PGP SIGNED MESSAGE-----


This is a FYI post. 

Hi, I had an email to bind9-workers stuck in my queue. It seemed to get
to the DATA stage, and then hung.

Running /var/spool/mqueue/h7J09Yd02119 (sequence 1 of 1)
<bind9-workers@isc.org>... Connecting to mx-2.isc.org. via esmtp...
220 skid.isc.org ESMTP Postfix
>>> EHLO noxmail.sandelman.ottawa.on.ca
250-skid.isc.org
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250 8BITMIME
>>> MAIL From:<mcr@sandelman.ottawa.on.ca> SIZE=4829 BODY=8BITMIME
250 Ok
>>> RCPT To:<bind9-workers@isc.org>
250 Ok
>>> DATA
354 End data with <CR><LF>.<CR><LF>
>>> .						<- HUNG HERE
250 Ok: queued as 7B62A8D646
<bind9-workers@isc.org>... Sent (Ok: queued as 7B62A8D646)

I poked at it a lot with tcpdump, but saw nothing. Then I noticed that
there was a AAAA record for mx-2.isc.org. Aha... I told tcpdump what to
look for and saw that the data was going out fragmented!

I wondered what was up, and why this was happening leaving my system.

My default route was:

                                                              mtu   
default   fe80::280:c8ff:feca:766c%vr0   UG          4    738  -  vr0

I poked at it by doing:

route change -inet6 -net -mtu 1280 :: fe80::280:c8ff:feca:766c

and tried to see if that helped, and I think that it did, the route wound
up as:

default   fe80::280:c8ff:feca:766c       UG          2      742  33220  lo0

which I don't get... why lo0?

Note that this system is a bit weird. It has two interfaces (ex0/vr0).

vr0 sits on a somewhat protected LAN with some other pop mail servers. 
It also has a NetBSD router which does router advertisements of a 2002:
that it has an stf0 for, as well as a GRE tunnel to he.net (and a route
for the rest of IPv6 land).
So, for non-2002: stuff, IPv6 packets go out vr0 with a 2002: address
that it got from RA.

ex0 sits on a different network, behind a FreeSWAN Opportunistic Encryption
gateway. There is an stf0 configured on that interface, which is the listed
IPv6 for incoming SMTP. The idea is that the v6-or-v4 packet will perhaps
get encrypted. the 2002::/16 route points out there, of course.
The IPv4 default also points in this direction. 

If someone can shed some light on why there were fragments going out,
that would be great. Alas, I don't have a dump, but I may try to reproduce
this if I'm able.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat

iQCVAwUBP0P3R4qHRg3pndX9AQFNTAP/Qua/E899c3OEBhecmMyH1QcVATyv1DFn
Y7V92qteKWcYy1Jw7/f6c0RlC+Pzq2E9WGudS4O9UXZa/N/jyuUkmQ8hbCs1drmO
XCG1nvHlRe7juxYyqbYvtHJQdEH+EsvwNofpVAbDuomFRLZ+dSdDrA0uwVYS3ZIK
7AjKUMzUbsk=
=mJ/H
-----END PGP SIGNATURE-----