Re: IPv4 socket bind using IPv6 socket on openjdk6 breaks udp send

2011-06-25 Thread Steven Hartland


- Original Message - 
From: Matthias Andree matthias.and...@gmx.de


I'm adding back in -java as based on you comments it may well be
something in the jdk passing invalid values down to the kernel
syscall.


The socket bind works fine and the packets sent to the server arrive
and are processed by the app but when it tries to reply using
send the result is:-
java.io.IOException: Invalid argument
   at java.net.PlainDatagramSocketImpl.send(Native Method)
   at java.net.DatagramSocket.send(DatagramSocket.java:629)

using truss we see the following:-
socket(PF_INET6,SOCK_DGRAM,0)= 20 (0x14)
setsockopt(0x14,0x29,0x1b,0x7edf0318,0x4,0x0) = 0 (0x0)
setsockopt(0x14,0x,0x20,0x7edf031c,0x4,0x0) = 0 (0x0)
bind(20,{ AF_INET6 [3800::10:0:0:0]:20736 },28)  = 0 (0x0)
..
sendto(20,\M^?\M^?\M^?\M^?I\aMultiplay :: ...,82,0x0,{ AF_INET6
[3800::10:0:0:0]:20736 },0x1c) ERR#22 'Invalid argument'


You're trying to send to your own address, but you're likely not using
the loopback interface for that.  Is that permitted by your firewall
configuration and routing?


No I'm not its replying to the sender. In the java code we have:-
socket.send( new DatagramPacket( data, data.length, src.getSocketAddress() ) );
Where src is the src packet. This works fine on IPv4 only machines and
when the jdk is told to use only IPv4 stack. So its not a problem with
the java code itself but could well be an issue with the




sockstat shows it binding correctly
root java   894   21 tcp4   85.236.109.212:25675  *:*


This is unrelated, as it has fd #21 not #20 as in the socket/bind/sendto
calls.  You've quoted the wrong line from sockstat output.


Oops sorry cut and paste error (wrong line) heres the correct line.
root java   894   20 udp4   85.236.109.212:25675  *:*

21 is the tcp port created in the same manor (ipv6 socket) which works
fine.




Note: net.inet6.ip6.v6only was set to the default 1 but changing
it to 0 has no effect on the issue.


You aren't using IPv4 mapped addresses, and you haven't stated whether
you're using wildcard listeners. Only in that case would it matter.


I'm not, its a bound port, as shown above now I have the correct line ;-)


inet6(4) reads:

 IPV6CTL_V6ONLY(ip6.v6only) Boolean: enable/disable the prohib-
   ited use of IPv4 mapped address on AF_INET6 sock-
   ets.  Defaults to on.


The jvm automatically sets this on all sockets for compatibility for
this exact reason. I'm not rulling out an issue with the IPv6 - v4
routing in the kernel though.


Are you sure that's what you seeing?  It's not a match for what you give
above, but anyways it's an implementation artifact because the tcp code
for v4 and v6 used to be shared and the udp code separate.


Thats not how the jdk works, its ment to be 100% transparent but isn't.
See the following for some interesting details:-
http://diario.beerensalat.info/2008/10/12/java_and_ipv6_on_bsd.html


It is best to set up one IPv4 and one IPv6 listening socket.


I don't believe there is any way to do this in java it either uses the
IPv4 stack only or the IPv6 stack only hence relies on the kernel
routing IPv4 packets through the IPv6 stack.

Thats the reason the jdk explicitly enables this for all the ports it
creates, which was added as a back port of the jdk7 fixes which can
be seen here:-
http://www.freebsd.org/cgi/cvsweb.cgi/ports/java/openjdk6/files/patch-set


Check the URL above, perhaps that helps your understanding a bit.  I
presume 3800::10:0:0:0 is your server?


Not that I'm aware of, here's the output from ifconfig if anyone can
tell me different, as I'm new to IPv6 and don't follow how its mapped
yet.

ifconfig
igb0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
   
options=1bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4
   ether 00:25:90:2c:3c:b0
   inet 85.236.109.212 netmask 0xff00 broadcast 85.236.109.255
   inet6 fe80::225:90ff:fe2c:3cb0%igb0 prefixlen 64 scopeid 0x1 
   inet6 2001:4db0:20:2::1337 prefixlen 64 
   nd6 options=3PERFORMNUD,ACCEPT_RTADV

   media: Ethernet autoselect (1000baseSX full-duplex)
   status: active
igb1: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500
   
options=1bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4
   ether 00:25:90:2c:3c:b1
   media: Ethernet autoselect (1000baseSX full-duplex)
   status: active
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
   options=3RXCSUM,TXCSUM
   inet 127.0.0.1 netmask 0xff00 
   inet6 ::1 prefixlen 128 
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 
   nd6 options=3PERFORMNUD,ACCEPT_RTADV


This is currently running on 8.2-RELEASE with openjdk6-b22_5

   Regards
   Steve


This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the 

Re: tar has deficient error handling. send-pr fix sent 31 Jan 2011

2011-06-25 Thread Tim Kientzle
Thanks for the reminder Julian.

I've just committed a fix to trunk that I'd appreciate if you could look at.

 Might be nice if someone else would read through tar.

More eyes are always better!  I'd especially appreciate help
improving the test suite for tar.  I've put a lot of work into
the test suite for libarchive, but the tar front-end has seen
less effort in this area.

Cheers,

Tim

On Jun 23, 2011, at 9:20 AM, Julian H. Stacey wrote:

 FreeBSD tar has deficient error handling.  I sent a fix 31 Jan 2011
   http://www.freebsd.org/cgi/query-pr.cgi?pr=154407
 Please commit the fix or write  commit a better fix.
 
 As error codes ignored, I wonder if other poor coding may lurk in tar.  
 Might be nice if someone else would read through tar.
 
 ports/ : Tar allows some errors in ports pkg-list to go un-noticed.
  Using make package, tar fails to see errors, fails to return error
  to make, some pkg-list not checked properly  accumulate errors,
  A bunch of errors will probably show up when tar is fixed, the
  more the longer we do nothing.  ( I can't remember which pkg-list
  are broken, I've not kept note, The solution is to read tar 
  commit a fix to tar ASAP)
 
 Cheers,
 Julian
 -- 
 Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
 Reply below, not above;  Indent with  ;  Cumulative like a play script.
 Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable.
 ___
 freebsd-hackers@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
 To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Include file search path

2011-06-25 Thread Arnaud Lacombe
Hi,

On Mon, Jun 6, 2011 at 5:37 PM, Arnaud Lacombe lacom...@gmail.com wrote:
 Hi,

 On Tue, May 31, 2011 at 12:23 PM, Warner Losh i...@bsdimp.com wrote:

 On May 22, 2011, at 9:48 PM, Arnaud Lacombe wrote:

 Hi Warner,

 On Sat, Apr 2, 2011 at 6:49 PM, Warner Losh i...@bsdimp.com wrote:

 On Apr 2, 2011, at 1:10 PM, Robert N. M. Watson wrote:

 On 2 Apr 2011, at 19:47, Warner Losh wrote:

 (2) Working clang/LLVM cross-compile of FreeBSD.  This seems like a 
 basic
  requirement to adopt clang/LLVM, and as far as I'm aware that's not 
 yet a
  resolved issue?

 0 work has been done here to my knowledge.  The world view for clang and 
 our in-tree gcc differ which makes it a challenge.

 That's disappointing. I seem to recall it's more an issue of our build 
 integration with clang/LLVM than an underlying issue in clang/LLVM?

 Yes.  The problem isn't hard, the cross compile paradigm is just a little 
 different.

 We (Cambridge) are currently bringing up FreeBSD on a new soft-core 
 64-bit MIPS platform.  We're already using a non-base gcc for our boot 
 loader work, and plan to move to using clang/LLVM later in the year.  
 The base system seems a bit short on detail when it comes to the above, 
 currently.

 Yes.  I've had to add about a dozen changes so far to get close to 
 building with xdev compilers.  A similar number are needed to make it 
 easy to configure and add systree support, I think.

 Sounds like great progress -- do you think we'll ship 9.0 in a just 
 works state with regard to this?

 I sure hope so.  I'd like to have demoable stuff by BSDcan.

 BSDCan has passed, has there been any advance made since that discussion ?

 It is demonstrable but not ready to commit to the tree.  Needs about 4 
 hours of work that I've had trouble scheduling on it due to work getting 
 busier than I expected.

 any chances to have a look at the patch or should I wait for the final commit 
 ?

ping ?

 - Arnaud
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org