At 1:52 AM +0900 10/3/01, Hajimu UMEMOTO wrote: > >>>>> On Tue, 2 Oct 2001 12:30:33 -0400 > >>>>> Garance A Drosihn <[EMAIL PROTECTED]> said: >drosih> The print queue for 'lp' on oink refers to a remote machine that >drosih> is named neutron. That hostname maps to an IPv6 address. Thus, >drosih> lpq/lpr/lprm have no choice on how to connect to that remote host. >drosih> They use the IPv6 address. (note, for instance, that your 'ping6' >drosih> knows about neutron via IPv6, not IPv4). So, the print client >drosih> connects to the print server via IPv6. When the print client >drosih> connects to the print server, the print server looks up the IPv6 >drosih> address of the *client*, because the client made an IPv6 connection >drosih> to the server. Again, this has nothing to do with 'lpd -4' on the >drosih> client. The print server apparently can not find a hostname to >drosih> match the IPv6 address of the client, so it returns the first error >drosih> message, listing the IPv6 address of the client. > >No, a client does query AAAA RR for IPv6 and A RR for IPv4. If AAAA >RR is found, a client tries to connect using IPv6, 1st. However, lpd >accepts only IPv4 connection, in this case. Then, if A RR is found, a >client falls down and tries to connect using IPv4. So, a client never >connects using IPv6 to an IPv4 only listening server.
Let me see if I have everything figured out now. If I understand what Alex has said, 1) on the print client, lpd is started with 'lpd -4' 2) he has not said how lpd is started on the print server. 3) because the print server came back with the error of "Host name for your address (fe80::250:baff:fed4:a512%xl0) unknown" I assume the print server, in this case, was NOT running with 'lpd -4'. Thus, the IPv6 connection DID work, but the print server could not come up with the hostname for the IPv6 address. 4) when he changed the print client to explicitly use the IPv4 address, the print server came back with an error message of "Host name for your address (192.168.0.19) unknown" This implies that when an IPv4 connection is made to the print server, the print server does it's reverse-lookup using the IPv4 address of the client. Since this works as expected, that again implies that the error message in part #3 does mean that the print server did get an IPv6 connection from the client. All this makes sense to me (I think...), although it looked wrong to Alex because he was seeing that IPv6 address in the message from the print server. Of course, I first need to find out how lpd was started on the print *server* (neutron), as opposed to the print client. #1, above, is irrelevant to how lpq on the client will connect to a remote machine. If 'lpd' is not started with -4 on his print server, then I think this all makes sense, and everything worked as I would expect it to. The only change to lpr which might be worth making is to add an 'rm4=' option to possible printcap settings for a queue, which would be like 'rm=' except that it would not even attempt to make an IPv6 connection. I'm not sure that's really necessary, but there might be situations where it would be useful. It might be that a particular hostname does have an IPv6 address, for instance, but for some reason it would be better to make an IPv4 connection to it. If people think this would be useful, I could add it, or something like it. Other than that one change, I think the code in lpr is working right, and no changes need to be made for the situation that Alex describes. -- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message