From owner-freebsd-net@FreeBSD.ORG Sun Apr 13 04:35:28 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 180A037B401 for ; Sun, 13 Apr 2003 04:35:28 -0700 (PDT) Received: from ntli.com (pc1-glfd2-4-cust59.glfd.cable.ntl.com [81.99.187.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20A6B43F85 for ; Sun, 13 Apr 2003 04:35:26 -0700 (PDT) (envelope-from william@palfreman.com) Received: from aqua.lan.palfreman.com (localhost [127.0.0.1]) by ntli.com (8.12.3p2/8.12.3) with ESMTP id h3DBgLuG075458 for ; Sun, 13 Apr 2003 12:42:21 +0100 (BST) (envelope-from william@palfreman.com) Received: from localhost (william@localhost)h3DBgLeX075455 for ; Sun, 13 Apr 2003 12:42:21 +0100 (BST) X-Authentication-Warning: aqua.lan.palfreman.com: william owned process doing -bs Date: Sun, 13 Apr 2003 12:42:21 +0100 (BST) From: William Palfreman To: net@freebsd.org Message-ID: <20030413123213.T40826@ndhn.yna.cnyserzna.pbz> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1073977242-1050184939=:40826" Content-ID: <20030412230249.K40826@ndhn.yna.cnyserzna.pbz> Subject: Freenet6: spreading IPv6 addresses to the LAN (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2003 11:35:28 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1073977242-1050184939=:40826 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20030412230249.S40826@ndhn.yna.cnyserzna.pbz> [Reposted to net@] I'm having trouble autoconfiguring IPv6 addresses. I've have my FreeBSD 4.8-RELEASE firewall successfully configured with Freenet6, with a /48 prefix. I can ping6 other sites: # ping6 -c 3 www2.at.freebsd.org PING6(56=40+8+8 bytes) 3ffe:b80:3:75b7::2 --> 2001:628:402:1:202:a5ff:fefb:40cb 16 bytes from 2001:628:402:1:202:a5ff:fefb:40cb, icmp_seq=0 hlim=50 time=516.289 ms 16 bytes from 2001:628:402:1:202:a5ff:fefb:40cb, icmp_seq=1 hlim=50 time=547.238 ms 16 bytes from 2001:628:402:1:202:a5ff:fefb:40cb, icmp_seq=2 hlim=50 time=575.88ms --- www2.at.freebsd.org ping6 statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/std-dev = 516.289/546.469/575.880/24.334 ms What I would like to do now is use autoconfiguration to allocate ipv6 addresses to other hosts on the lan. It isn't happening. Below is a selection of (hopefully) relevant information about my setup: # tspc -v tspc - Tunnel Server Protocol Client Loading configuration file Connecting to server Using [81.99.187.59] as source IPv4 address. Send request Process response from server TSP_HOST_TYPE router TSP_TUNNEL_INTERFACE gif0 TSP_HOME_INTERFACE rl1 TSP_CLIENT_ADDRESS_IPV4 81.99.187.59 TSP_CLIENT_ADDRESS_IPV6 3ffe:0b80:0003:75b7:0000:0000:0000:0002 TSP_SERVER_ADDRESS_IPV4 206.123.31.114 TSP_SERVER_ADDRESS_IPV6 3ffe:0b80:0003:75b7:0000:0000:0000:0001 TSP_TUNNEL_PREFIXLEN 128 TSP_PREFIX 3ffe:0b80:1d83 TSP_PREFIXLEN 48 TSP_VERBOSE 1 TSP_HOME_DIR /usr/local --- Start of configuration script. --- Script: tspc-freebsd44.sh Setting up interface gif0 Adding default route to 3ffe:0b80:0003:75b7:0000:0000:0000:0001 route: writing to routing socket: No such process delete net default: not in table add net default: gateway 3ffe:0b80:0003:75b7:0000:0000:0000:0001 Router configuration Kernel setup route: writing to routing socket: File exists add net 3ffe:0b80:1d83::: gateway lo0: File exists Error while executing /sbin/route Command: /sbin/route add -inet6 3ffe:0b80:1d83:: -prefixlen 48 -interface lo0 Closing, exit status: 0 Exiting with return code : 0 (0 = no error) # ifconfig rl1 && ifconfig gif0 && ifconfig rl0 rl1: flags=8843 mtu 1500 inet6 fe80::2e0:7dff:fe96:13bc%rl1 prefixlen 64 scopeid 0x2 inet 81.99.187.59 netmask 0xffffff00 broadcast 255.255.255.255 inet6 3ffe:b80:1d83:1::1 prefixlen 64 ether 00:e0:7d:96:13:bc media: Ethernet autoselect (100baseTX ) status: active gif0: flags=8051 mtu 1280 tunnel inet 81.99.187.59 --> 206.123.31.114 inet6 3ffe:b80:3:75b7::2 --> 3ffe:b80:3:75b7::1 prefixlen 128 inet6 fe80::200:b4ff:fe93:4e34%gif0 prefixlen 64 scopeid 0x8 rl0: flags=8843 mtu 1500 inet 10.23.90.62 netmask 0xffffffc0 broadcast 10.23.90.63 inet6 fe80::200:b4ff:fe93:4e34%rl0 prefixlen 64 scopeid 0x1 ether 00:00:b4:93:4e:34 media: Ethernet autoselect (10baseT/UTP) status: active # ps ax | grep route && ps ax | grep rta 139 ?? Is 0:01.44 /usr/sbin/route6d 589 p0 R+ 0:00.02 grep route 229 ?? Is 0:00.22 /usr/sbin/rtadvd -c /usr/local/tsprtadvd.conf rl1 # cat /usr/local/tsprtadvd.conf ##### rtadvd.conf made by TSP #### default:\ :raflags#0:rltime#3600:\ :pinfoflags#64:vltime#360000:pltime#360000:mtu#1500: ether:\ :mtu#1280:tc=default: ## interfaces. rl1:\ :addrs#1:\ :addr="3ffe:0b80:1d83:0001::":prefixlen#64:tc=ether: # ip6fw show 00100 0 0 reset tcp from any to any 22 in recv rl1 setup 00200 0 0 reset tcp from any to any 25 in recv rl1 setup 00300 0 0 reset tcp from any to any 587 in recv rl1 setup 65535 1071 55724 allow ipv6 from any to any # grep ipv6 /etc/rc.conf ipv6_gateway_enable="YES" ipv6_enable="YES" ipv6_gateway_enable="YES" ipv6_router_enable="YES" ipv6_network_interfaces="gif0 rl0 rl1" # cat /usr/local/etc/tspc.conf tsp_version=1.0.1 tsp_dir=/usr/local auth_method=any client_v4=auto userid= passwd= template=freebsd44 server=tsps1.freenet6.net retry_delay=0 if_tunnel=gif0 host_type=router prefixlen=48 if_prefix=rl1 This is the information for the host I want to autoconfigure. It is also FreeBSD 4.8-RELEASE: $ grep ipv6 rc.conf ipv6_enable="YES" $ ifconfig fxp0 fxp0: flags=8843 mtu 1500 inet 10.23.90.2 netmask 0xffffffc0 broadcast 10.23.90.63 inet6 fe80::202:b3ff:fe23:bcfe%fxp0 prefixlen 64 scopeid 0x1 ether 00:02:b3:23:bc:fe media: Ethernet autoselect (100baseTX ) status: active Because it is an internal-only machine, it doesn't have any firewalling stuff in the kernel. I can ping6 its own link-local address, and the link-local address of the interface on the firewall that is connected to my LAN. "rtsol fxp0" doesn't seem to do anything on this machine - I still have the link-local as my only inet6 address for that interface. I don't think I need any other information, do I? I have attached the kernel config files for both hosts to this email. What do people think? I am missing something really obvious here? TIA, Bill. -- W. Palfreman. I'm looking for a job. Read my CV at: Tel: 0771 355 0354 www.palfreman.com/william/cv-wfp2.html --0-1073977242-1050184939=:40826 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=FW Content-Transfer-Encoding: BASE64 Content-ID: <20030412230219.H40826@ndhn.yna.cnyserzna.pbz> Content-Description: Kernel config for firewall Content-Disposition: ATTACHMENT; FILENAME=FW bWFjaGluZQkJaTM4Ng0KY3B1CQlJNTg2X0NQVQ0KaWRlbnQJCUZXDQptYXh1 c2VycwkwDQoNCiNtYWtlb3B0aW9ucwlERUJVRz0tZwkJI0J1aWxkIGtlcm5l bCB3aXRoIGdkYigxKSBkZWJ1ZyBzeW1ib2xzDQoNCm9wdGlvbnMgCUlORVQJ CQkjSW50ZXJORVR3b3JraW5nDQpvcHRpb25zIAlJTkVUNgkJCSNJUHY2IGNv bW11bmljYXRpb25zIHByb3RvY29scw0Kb3B0aW9ucwkJSVBTRUMNCm9wdGlv bnMgCUZGUwkJCSNCZXJrZWxleSBGYXN0IEZpbGVzeXN0ZW0NCm9wdGlvbnMg CUZGU19ST09UCQkjRkZTIHVzYWJsZSBhcyByb290IGRldmljZSBba2VlcCB0 aGlzIV0NCm9wdGlvbnMgCVNPRlRVUERBVEVTCQkjRW5hYmxlIEZGUyBzb2Z0 IHVwZGF0ZXMgc3VwcG9ydA0Kb3B0aW9ucyAJVUZTX0RJUkhBU0gJCSNJbXBy b3ZlIHBlcmZvcm1hbmNlIG9uIGJpZyBkaXJlY3Rvcmllcw0Kb3B0aW9ucyAJ TUZTCQkJI01lbW9yeSBGaWxlc3lzdGVtDQpvcHRpb25zIAlNRF9ST09UCQkJ I01EIGlzIGEgcG90ZW50aWFsIHJvb3QgZGV2aWNlDQpvcHRpb25zIAlORlMJ CQkjTmV0d29yayBGaWxlc3lzdGVtDQojb3B0aW9ucyAJTkZTX1JPT1QJCSNO RlMgdXNhYmxlIGFzIHJvb3QgZGV2aWNlLCBORlMgcmVxdWlyZWQNCiNvcHRp b25zIAlNU0RPU0ZTCQkJI01TRE9TIEZpbGVzeXN0ZW0NCiNvcHRpb25zIAlD RDk2NjAJCQkjSVNPIDk2NjAgRmlsZXN5c3RlbQ0KI29wdGlvbnMgCUNEOTY2 MF9ST09UCQkjQ0QtUk9NIHVzYWJsZSBhcyByb290LCBDRDk2NjAgcmVxdWly ZWQNCm9wdGlvbnMgCVBST0NGUwkJCSNQcm9jZXNzIGZpbGVzeXN0ZW0NCm9w dGlvbnMgCUNPTVBBVF80MwkJI0NvbXBhdGlibGUgd2l0aCBCU0QgNC4zIFtL RUVQIFRISVMhXQ0KI29wdGlvbnMgCVNDU0lfREVMQVk9MTUwMDAJI0RlbGF5 IChpbiBtcykgYmVmb3JlIHByb2JpbmcgU0NTSQ0Kb3B0aW9ucyAJVUNPTlNP TEUJCSNBbGxvdyB1c2VycyB0byBncmFiIHRoZSBjb25zb2xlDQpvcHRpb25z IAlVU0VSQ09ORklHCQkjYm9vdCAtYyBlZGl0b3INCm9wdGlvbnMgCVZJU1VB TF9VU0VSQ09ORklHCSN2aXN1YWwgYm9vdCAtYyBlZGl0b3INCm9wdGlvbnMg CUtUUkFDRQkJCSNrdHJhY2UoMSkgc3VwcG9ydA0Kb3B0aW9ucyAJU1lTVlNI TQkJCSNTWVNWLXN0eWxlIHNoYXJlZCBtZW1vcnkNCm9wdGlvbnMgCVNZU1ZN U0cJCQkjU1lTVi1zdHlsZSBtZXNzYWdlIHF1ZXVlcw0Kb3B0aW9ucyAJU1lT VlNFTQkJCSNTWVNWLXN0eWxlIHNlbWFwaG9yZXMNCm9wdGlvbnMgCVAxMDAz XzFCCQkjUG9zaXggUDEwMDNfMUIgcmVhbC10aW1lIGV4dGVuc2lvbnMNCm9w dGlvbnMgCV9LUE9TSVhfUFJJT1JJVFlfU0NIRURVTElORw0Kb3B0aW9ucyAJ S0JEX0lOU1RBTExfQ0RFVgkjIGluc3RhbGwgYSBDREVWIGVudHJ5IGluIC9k ZXYNCg0KZGV2aWNlCQlpc2ENCmRldmljZQkJZWlzYQ0KZGV2aWNlCQlwY2kN Cg0KIyBGbG9wcHkgZHJpdmVzDQojZGV2aWNlCQlmZGMwCWF0IGlzYT8gcG9y dCBJT19GRDEgaXJxIDYgZHJxIDINCiNkZXZpY2UJCWZkMAlhdCBmZGMwIGRy aXZlIDANCiNkZXZpY2UJCWZkMQlhdCBmZGMwIGRyaXZlIDENCiMNCiMgSWYg eW91IGhhdmUgYSBUb3NoaWJhIExpYnJldHRvIHdpdGggaXRzIFktRSBEYXRh IFBDTUNJQSBmbG9wcHksDQojIGRvbid0IHVzZSB0aGUgYWJvdmUgbGluZSBm b3IgZmRjMCBidXQgdGhlIGZvbGxvd2luZyBvbmU6DQojZGV2aWNlCQlmZGMw DQoNCiMgQVRBIGFuZCBBVEFQSSBkZXZpY2VzDQpkZXZpY2UJCWF0YTAJYXQg aXNhPyBwb3J0IElPX1dEMSBpcnEgMTQNCmRldmljZQkJYXRhMQlhdCBpc2E/ IHBvcnQgSU9fV0QyIGlycSAxNQ0KZGV2aWNlCQlhdGENCmRldmljZQkJYXRh ZGlzawkJCSMgQVRBIGRpc2sgZHJpdmVzDQpkZXZpY2UJCWF0YXBpY2QJCQkj IEFUQVBJIENEUk9NIGRyaXZlcw0KI2RldmljZQkJYXRhcGlmZAkJCSMgQVRB UEkgZmxvcHB5IGRyaXZlcw0KI2RldmljZQkJYXRhcGlzdAkJCSMgQVRBUEkg dGFwZSBkcml2ZXMNCm9wdGlvbnMgCUFUQV9TVEFUSUNfSUQJCSNTdGF0aWMg ZGV2aWNlIG51bWJlcmluZw0KDQojIFNDU0kgQ29udHJvbGxlcnMNCiNkZXZp Y2UJCWFoYgkJIyBFSVNBIEFIQTE3NDIgZmFtaWx5DQojZGV2aWNlCQlhaGMJ CSMgQUhBMjk0MCBhbmQgb25ib2FyZCBBSUM3eHh4IGRldmljZXMNCiNkZXZp Y2UJCWFtZAkJIyBBTUQgNTNDOTc0IChUZWtyYW0gREMtMzkwKFQpKQ0KI2Rl dmljZQkJaXNwCQkjIFFsb2dpYyBmYW1pbHkNCiNkZXZpY2UJCW5jcgkJIyBO Q1IvU3ltYmlvcyBMb2dpYw0KI2RldmljZQkJc3ltCQkjIE5DUi9TeW1iaW9z IExvZ2ljIChuZXdlciBjaGlwc2V0cykNCiNvcHRpb25zCQlTWU1fU0VUVVBf TFBfUFJPQkVfTUFQPTB4NDANCgkJCQkjIEFsbG93IG5jciB0byBhdHRhY2gg bGVnYWN5IE5DUiBkZXZpY2VzIHdoZW4gDQoJCQkJIyBib3RoIHN5bSBhbmQg bmNyIGFyZSBjb25maWd1cmVkDQoNCiNkZXZpY2UJCWFkdjAJYXQgaXNhPw0K I2RldmljZQkJYWR3DQojZGV2aWNlCQlidDAJYXQgaXNhPw0KI2RldmljZQkJ YWhhMAlhdCBpc2E/DQojZGV2aWNlCQlhaWMwCWF0IGlzYT8NCg0KI2Rldmlj ZQkJbmN2CQkjIE5DUiA1M0M1MDANCiNkZXZpY2UJCW5zcAkJIyBXb3JrYml0 IE5pbmphIFNDU0ktMw0KI2RldmljZQkJc3RnCQkjIFRNQyAxOEMzMC8xOEM1 MA0KDQojIFNDU0kgcGVyaXBoZXJhbHMNCmRldmljZQkJc2NidXMJCSMgU0NT SSBidXMgKHJlcXVpcmVkKQ0KI2RldmljZQkJZGEJCSMgRGlyZWN0IEFjY2Vz cyAoZGlza3MpDQojZGV2aWNlCQlzYQkJIyBTZXF1ZW50aWFsIEFjY2VzcyAo dGFwZSBldGMpDQojZGV2aWNlCQljZAkJIyBDRA0KI2RldmljZQkJcGFzcwkJ IyBQYXNzdGhyb3VnaCBkZXZpY2UgKGRpcmVjdCBTQ1NJIGFjY2VzcykNCg0K IyBSQUlEIGNvbnRyb2xsZXJzIGludGVyZmFjZWQgdG8gdGhlIFNDU0kgc3Vi c3lzdGVtDQojZGV2aWNlCQlhc3IJCSMgRFBUIFNtYXJ0UkFJRCBWLCBWSSBh bmQgQWRhcHRlYyBTQ1NJIFJBSUQNCiNkZXZpY2UJCWRwdAkJIyBEUFQgU21h cnRjYWNoZSAtIFNlZSBMSU5UIGZvciBvcHRpb25zIQ0KI2RldmljZSAgICAg ICAgICBpaXIgICAgICAgICAgICAgIyBJbnRlbCBJbnRlZ3JhdGVkIFJBSUQN CiNkZXZpY2UJCW1seQkJIyBNeWxleCBBY2NlbGVSQUlEL2VYdHJlbWVSQUlE DQojZGV2aWNlCQljaXNzCQkjIENvbXBhcSBTbWFydFJBSUQgNSogc2VyaWVz DQoNCiMgUkFJRCBjb250cm9sbGVycw0KI2RldmljZQkJYWFjCQkjIEFkYXB0 ZWMgRlNBIFJBSUQsIERlbGwgUEVSQzIvUEVSQzMNCiNkZXZpY2UJCWFhY3AJ CSMgU0NTSSBwYXNzdGhyb3VnaCBmb3IgYWFjIChyZXF1aXJlcyBDQU0pDQoj ZGV2aWNlCQlpZGEJCSMgQ29tcGFxIFNtYXJ0IFJBSUQNCiNkZXZpY2UJCWFt cgkJIyBBTUkgTWVnYVJBSUQNCiNkZXZpY2UJCW1seAkJIyBNeWxleCBEQUM5 NjAgZmFtaWx5DQojZGV2aWNlCQl0d2UJCSMgM3dhcmUgRXNjYWxhZGUNCg0K IyBhdGtiZGMwIGNvbnRyb2xzIGJvdGggdGhlIGtleWJvYXJkIGFuZCB0aGUg UFMvMiBtb3VzZQ0KZGV2aWNlCQlhdGtiZGMwCWF0IGlzYT8gcG9ydCBJT19L QkQNCmRldmljZQkJYXRrYmQwCWF0IGF0a2JkYz8gaXJxIDENCmRldmljZQkJ cHNtMAlhdCBhdGtiZGM/IGlycSAxMg0KDQpkZXZpY2UJCXZnYTAJYXQgaXNh Pw0KDQojIHNwbGFzaCBzY3JlZW4vc2NyZWVuIHNhdmVyDQpwc2V1ZG8tZGV2 aWNlCXNwbGFzaA0KDQojIHN5c2NvbnMgaXMgdGhlIGRlZmF1bHQgY29uc29s ZSBkcml2ZXIsIHJlc2VtYmxpbmcgYW4gU0NPIGNvbnNvbGUNCmRldmljZQkJ c2MwCWF0IGlzYT8gZmxhZ3MgMHgxMDANCg0KIyBFbmFibGUgdGhpcyBhbmQg UENWVF9GUkVFQlNEIGZvciBwY3Z0IHZ0MjIwIGNvbXBhdGlibGUgY29uc29s ZSBkcml2ZXINCiNkZXZpY2UJCXZ0MAlhdCBpc2E/DQojb3B0aW9ucyAJWFNF UlZFUgkJCSMgc3VwcG9ydCBmb3IgWCBzZXJ2ZXIgb24gYSB2dCBjb25zb2xl DQojb3B0aW9ucyAJRkFUX0NVUlNPUgkJIyBzdGFydCB3aXRoIGJsb2NrIGN1 cnNvcg0KIyBJZiB5b3UgaGF2ZSBhIFRoaW5rUEFELCB1bmNvbW1lbnQgdGhp cyBhbG9uZyB3aXRoIHRoZSByZXN0IG9mIHRoZSBQQ1ZUIGxpbmVzDQojb3B0 aW9ucyAJUENWVF9TQ0FOU0VUPTIJCSMgSUJNIGtleWJvYXJkcyBhcmUgbm9u LXN0ZA0KDQojIEZsb2F0aW5nIHBvaW50IHN1cHBvcnQgLSBkbyBub3QgZGlz YWJsZS4NCmRldmljZQkJbnB4MAlhdCBuZXh1cz8gcG9ydCBJT19OUFggaXJx IDEzDQoNCiMgU2VyaWFsIChDT00pIHBvcnRzDQpkZXZpY2UgICAgICAgICAg c2lvMCAgICBhdCBpc2E/IHBvcnQgSU9fQ09NMSBmbGFncyAweDMwIGlycSA0 DQpkZXZpY2UJCXNpbzEJYXQgaXNhPyBwb3J0IElPX0NPTTIgaXJxIDMNCiNk ZXZpY2UJCXNpbzIJYXQgaXNhPyBkaXNhYmxlIHBvcnQgSU9fQ09NMyBpcnEg NQ0KI2RldmljZQkJc2lvMwlhdCBpc2E/IGRpc2FibGUgcG9ydCBJT19DT000 IGlycSA5DQoNCiMgUGFyYWxsZWwgcG9ydA0KZGV2aWNlCQlwcGMwCWF0IGlz YT8gaXJxIDcNCmRldmljZQkJcHBidXMJCSMgUGFyYWxsZWwgcG9ydCBidXMg KHJlcXVpcmVkKQ0KZGV2aWNlCQlscHQJCSMgUHJpbnRlcg0KI2RldmljZQkJ cGxpcAkJIyBUQ1AvSVAgb3ZlciBwYXJhbGxlbA0KI2RldmljZQkJcHBpCQkj IFBhcmFsbGVsIHBvcnQgaW50ZXJmYWNlIGRldmljZQ0KI2RldmljZQkJdnBv CQkjIFJlcXVpcmVzIHNjYnVzIGFuZCBkYQ0KDQoNCiMgUENJIEV0aGVybmV0 IE5JQ3MuDQojZGV2aWNlCQlkZQkJIyBERUMvSW50ZWwgREMyMXg0eCAoYGBU dWxpcCcnKQ0KI2RldmljZQkJZW0JCSMgSW50ZWwgUFJPLzEwMDAgYWRhcHRl ciBHaWdhYml0IEV0aGVybmV0IENhcmQgKGBgV2lzZW1hbicnKQ0KI2Rldmlj ZQkJdHhwCQkjIDNDb20gM2NSOTkwIChgYFR5cGhvb24nJykNCiNkZXZpY2UJ CXZ4CQkjIDNDb20gM2M1OTAsIDNjNTk1IChgYFZvcnRleCcnKQ0KDQojIFBD SSBFdGhlcm5ldCBOSUNzIHRoYXQgdXNlIHRoZSBjb21tb24gTUlJIGJ1cyBj b250cm9sbGVyIGNvZGUuDQojIE5PVEU6IEJlIHN1cmUgdG8ga2VlcCB0aGUg J2RldmljZSBtaWlidXMnIGxpbmUgaW4gb3JkZXIgdG8gdXNlIHRoZXNlIE5J Q3MhDQpkZXZpY2UJCW1paWJ1cwkJIyBNSUkgYnVzIHN1cHBvcnQNCiNkZXZp Y2UJCWRjCQkjIERFQy9JbnRlbCAyMTE0MyBhbmQgdmFyaW91cyB3b3JrYWxp a2VzDQojZGV2aWNlCQlmeHAJCSMgSW50ZWwgRXRoZXJFeHByZXNzIFBSTy8x MDBCICg4MjU1NywgODI1NTgpDQojZGV2aWNlCQlwY24JCSMgQU1EIEFtNzlD OTd4IFBDSSAxMC8xMDAgTklDcw0KZGV2aWNlCQlybAkJIyBSZWFsVGVrIDgx MjkvODEzOQ0KI2RldmljZQkJc2YJCSMgQWRhcHRlYyBBSUMtNjkxNSAoYGBT dGFyZmlyZScnKQ0KI2RldmljZQkJc2lzCQkjIFNpbGljb24gSW50ZWdyYXRl ZCBTeXN0ZW1zIFNpUyA5MDAvU2lTIDcwMTYNCiNkZXZpY2UJCXN0ZQkJIyBT dW5kYW5jZSBTVDIwMSAoRC1MaW5rIERGRS01NTBUWCkNCiNkZXZpY2UJCXRs CQkjIFRleGFzIEluc3RydW1lbnRzIFRodW5kZXJMQU4NCiNkZXZpY2UJCXR4 CQkjIFNNQyBFdGhlclBvd2VyIElJICg4M2MxNzAgYGBFUElDJycpDQojZGV2 aWNlCQl2cgkJIyBWSUEgUmhpbmUsIFJoaW5lIElJDQojZGV2aWNlCQl3YgkJ IyBXaW5ib25kIFc4OUM4NDBGDQojZGV2aWNlCQl4bAkJIyAzQ29tIDNjOTB4 IChgYEJvb21lcmFuZycnLCBgYEN5Y2xvbmUnJykNCiNkZXZpY2UJCWJnZQkJ IyBCcm9hZGNvbSBCQ001NzB4IChgYFRpZ29uIElJSScnKQ0KDQojIElTQSBF dGhlcm5ldCBOSUNzLg0KIyAnZGV2aWNlIGVkJyByZXF1aXJlcyAnZGV2aWNl IG1paWJ1cycNCmRldmljZQkJZWQwCWF0IGlzYT8gcG9ydCAweDI4MCBpcnEg MTAgaW9tZW0gMHhkODAwMA0KI2RldmljZQkJZXgNCiNkZXZpY2UJCWVwDQoj ZGV2aWNlCQlmZTAJYXQgaXNhPyBwb3J0IDB4MzAwDQojIFhpcmNvbSBFdGhl cm5ldA0KI2RldmljZQkJeGUNCiMgUFJJU00gSSBJRUVFIDgwMi4xMWIgd2ly ZWxlc3MgTklDLg0KI2RldmljZQkJYXdpDQojIFdhdmVMQU4vSUVFRSA4MDIu MTEgd2lyZWxlc3MgTklDcy4gTm90ZTogdGhlIFdhdmVMQU4vSUVFRSByZWFs bHkNCiMgZXhpc3RzIG9ubHkgYXMgYSBQQ01DSUEgZGV2aWNlLCBzbyB0aGVy ZSBpcyBubyBJU0EgYXR0YWNobWVudCBuZWVkZWQNCiMgYW5kIHJlc291cmNl cyB3aWxsIGFsd2F5cyBiZSBkeW5hbWljYWxseSBhc3NpZ25lZCBieSB0aGUg cGNjYXJkIGNvZGUuDQojZGV2aWNlCQl3aQ0KIyBBaXJvbmV0IDQ1MDAvNDgw MCA4MDIuMTEgd2lyZWxlc3MgTklDcy4gTm90ZTogdGhlIGRlY2xhcmF0aW9u IGJlbG93IHdpbGwNCiMgd29yayBmb3IgUENNQ0lBIGFuZCBQQ0kgY2FyZHMs IGFzIHdlbGwgYXMgSVNBIGNhcmRzIHNldCB0byBJU0EgUG5QDQojIG1vZGUg KHRoZSBmYWN0b3J5IGRlZmF1bHQpLiBJZiB5b3Ugc2V0IHRoZSBzd2l0Y2hl cyBvbiB5b3VyIElTQQ0KIyBjYXJkIGZvciBhIG1hbnVhbGx5IGNob3NlbiBJ L08gYWRkcmVzcyBhbmQgSVJRLCB5b3UgbXVzdCBzcGVjaWZ5DQojIHRob3Nl IHBhcmFtZXRlcnMgaGVyZS4NCiNkZXZpY2UJCWFuDQojIFRoZSBwcm9iZSBv cmRlciBvZiB0aGVzZSBpcyBwcmVzZW50bHkgZGV0ZXJtaW5lZCBieSBpMzg2 L2lzYS9pc2FfY29tcGF0LmMuDQojZGV2aWNlCQlpZTAJYXQgaXNhPyBwb3J0 IDB4MzAwIGlycSAxMCBpb21lbSAweGQwMDAwDQojZGV2aWNlCQlsZTAJYXQg aXNhPyBwb3J0IDB4MzAwIGlycSA1IGlvbWVtIDB4ZDAwMDANCiNkZXZpY2UJ CWxuYzAJYXQgaXNhPyBwb3J0IDB4MjgwIGlycSAxMCBkcnEgMA0KI2Rldmlj ZQkJY3MwCWF0IGlzYT8gcG9ydCAweDMwMA0KI2RldmljZQkJc24wCWF0IGlz YT8gcG9ydCAweDMwMCBpcnEgMTANCg0KIyBQc2V1ZG8gZGV2aWNlcyAtIHRo ZSBudW1iZXIgaW5kaWNhdGVzIGhvdyBtYW55IHVuaXRzIHRvIGFsbG9jYXRl Lg0KcHNldWRvLWRldmljZQlsb29wCQkjIE5ldHdvcmsgbG9vcGJhY2sNCnBz ZXVkby1kZXZpY2UJZXRoZXIJCSMgRXRoZXJuZXQgc3VwcG9ydA0KI3BzZXVk by1kZXZpY2UgICB2bGFuICAgIDIgICAgICAgIyBWTEFOIHN1cHBvcnQNCiNw c2V1ZG8tZGV2aWNlCXNsCTEJIyBLZXJuZWwgU0xJUA0KcHNldWRvLWRldmlj ZQlwcHAJMgkjIEtlcm5lbCBQUFANCnBzZXVkby1kZXZpY2UJdHVuCQkjIFBh Y2tldCB0dW5uZWwuDQpwc2V1ZG8tZGV2aWNlCXB0eQkJIyBQc2V1ZG8tdHR5 cyAodGVsbmV0IGV0YykNCnBzZXVkby1kZXZpY2UJbWQJCSMgTWVtb3J5ICJk aXNrcyINCnBzZXVkby1kZXZpY2UJZ2lmCQkjIElQdjYgYW5kIElQdjQgdHVu bmVsaW5nDQpwc2V1ZG8tZGV2aWNlCWZhaXRoCTEJIyBJUHY2LXRvLUlQdjQg cmVsYXlpbmcgKHRyYW5zbGF0aW9uKQ0Kb3B0aW9ucyAgICAgICAgIFBQUF9C U0RDT01QICAgICAjIFBQUCBCU0QtY29tcHJlc3Mgc3VwcG9ydA0Kb3B0aW9u cyAgICAgICAgIFBQUF9ERUZMQVRFICAgICAjIFBQUCB6bGliL2RlZmxhdGUv Z3ppcCBzdXBwb3J0DQpwc2V1ZG8tZGV2aWNlICAgc3RmICAgICAgICAgICAg ICMgNnRvNCBJUHY2IG92ZXIgSVB2NCBlbmNhcHN1bGF0aW9uDQoNCiMgVGhl IGBicGYnIHBzZXVkby1kZXZpY2UgZW5hYmxlcyB0aGUgQmVya2VsZXkgUGFj a2V0IEZpbHRlci4NCiMgQmUgYXdhcmUgb2YgdGhlIGFkbWluaXN0cmF0aXZl IGNvbnNlcXVlbmNlcyBvZiBlbmFibGluZyB0aGlzIQ0KcHNldWRvLWRldmlj ZQlicGYJCSNCZXJrZWxleSBwYWNrZXQgZmlsdGVyDQpvcHRpb25zICAgICAg ICAgUFBQX0ZJTFRFUiAgICAgICNlbmFibGUgYnBmIGZpbHRlcmluZyAobmVl ZHMgYnBmKQ0KDQpvcHRpb25zICAgICAgICAgTVJPVVRJTkcgICAgICAgICAg ICAgICAgIyBNdWx0aWNhc3Qgcm91dGluZw0Kb3B0aW9ucyAgICAgICAgIElQ RklSRVdBTEwgICAgICAgICAgICAgICNmaXJld2FsbA0Kb3B0aW9ucyAgICAg ICAgIElQRklSRVdBTExfVkVSQk9TRSAgICAgICNlbmFibGUgbG9nZ2luZyB0 byBzeXNsb2dkKDgpDQpvcHRpb25zICAgICAgICAgSVBGSVJFV0FMTF9GT1JX QVJEICAgICAgI2VuYWJsZSB0cmFuc3BhcmVudCBwcm94eSBzdXBwb3J0DQpv cHRpb25zICAgICAgICAgSVBGSVJFV0FMTF9WRVJCT1NFX0xJTUlUPTEwMCAg ICAjbGltaXQgdmVyYm9zaXR5DQpvcHRpb25zICAgICAgICAgSVBWNkZJUkVX QUxMICAgICAgICAgICAgI2ZpcmV3YWxsIGZvciBJUHY2DQpvcHRpb25zICAg ICAgICAgSVBWNkZJUkVXQUxMX1ZFUkJPU0UNCm9wdGlvbnMgICAgICAgICBJ UFY2RklSRVdBTExfVkVSQk9TRV9MSU1JVD0xMDANCiNvcHRpb25zCUlQVjZG SVJFV0FMTF9ERUZBVUxUX1RPX0FDQ0VQVA0Kb3B0aW9ucyAgICAgICAgIElQ RElWRVJUICAgICAgICAgICAgICAgICNkaXZlcnQgc29ja2V0cw0Kb3B0aW9u cyAgICAgICAgIElQRklMVEVSICAgICAgICAgICAgICAgICNpcGZpbHRlciBz dXBwb3J0DQpvcHRpb25zICAgICAgICAgSVBGSUxURVJfTE9HICAgICAgICAg ICAgI2lwZmlsdGVyIGxvZ2dpbmcNCiNvcHRpb25zICAgICAgICAgSVBGSUxU RVJfREVGQVVMVF9CTE9DSyAgI2Jsb2NrIGFsbCBwYWNrZXRzIGJ5IGRlZmF1 bHQNCm9wdGlvbnMgICAgICAgICBJUFNURUFMVEggICAgICAgICAgICAgICAj c3VwcG9ydCBmb3Igc3RlYWx0aCBmb3J3YXJkaW5nDQpvcHRpb25zICAgICAg ICAgUkFORE9NX0lQX0lEDQpvcHRpb25zCQlJQ01QX0JBTkRMSU0JCSNSYXRl IGxpbWl0IGJhZCByZXBsaWVzDQpvcHRpb25zICAgICAgICAgRFVNTVlORVQN Cm9wdGlvbnMgICAgICAgICBCUklER0UNCm9wdGlvbnMgCUhaPTEwMDANCm9w dGlvbnMgICAgICAgICBRVU9UQSAgICAgICAgICAgICAgICAgICAjZW5hYmxl IGRpc2sgcXVvdGFzDQojcHNldWRvLWRldmljZSAgIHNwZWFrZXINCiNwc2V1 ZG8tZGV2aWNlICAgc25wDQo= --0-1073977242-1050184939=:40826 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=LEDGER Content-Transfer-Encoding: BASE64 Content-ID: <20030412230219.S40826@ndhn.yna.cnyserzna.pbz> Content-Description: Kernel config for other host Content-Disposition: ATTACHMENT; FILENAME=LEDGER bWFjaGluZQkJaTM4Ng0KY3B1CQlJNTg2X0NQVQ0KaWRlbnQJCUxFREdFUg0K bWF4dXNlcnMJMA0KDQojbWFrZW9wdGlvbnMJREVCVUc9LWcJCSNCdWlsZCBr ZXJuZWwgd2l0aCBnZGIoMSkgZGVidWcgc3ltYm9scw0KDQpvcHRpb25zIAlJ TkVUCQkJI0ludGVyTkVUd29ya2luZw0Kb3B0aW9ucyAJSU5FVDYJCQkjSVB2 NiBjb21tdW5pY2F0aW9ucyBwcm90b2NvbHMNCm9wdGlvbnMgICAgICAgICBJ UFNFQyAgICAgICAgICAgICAgICAgICAjSVAgc2VjdXJpdHkNCm9wdGlvbnMg ICAgICAgICBJUFNFQ19FU1AgICAgICAgICAgICAgICAjSVAgc2VjdXJpdHkg KGNyeXB0bzsgZGVmaW5lIHcvIElQU0VDKQ0Kb3B0aW9ucyAJRkZTCQkJI0Jl cmtlbGV5IEZhc3QgRmlsZXN5c3RlbQ0Kb3B0aW9ucyAJRkZTX1JPT1QJCSNG RlMgdXNhYmxlIGFzIHJvb3QgZGV2aWNlIFtrZWVwIHRoaXMhXQ0Kb3B0aW9u cyAJU09GVFVQREFURVMJCSNFbmFibGUgRkZTIHNvZnQgdXBkYXRlcyBzdXBw b3J0DQpvcHRpb25zIAlVRlNfRElSSEFTSAkJI0ltcHJvdmUgcGVyZm9ybWFu Y2Ugb24gYmlnIGRpcmVjdG9yaWVzDQpvcHRpb25zIAlNRlMJCQkjTWVtb3J5 IEZpbGVzeXN0ZW0NCm9wdGlvbnMgCU1EX1JPT1QJCQkjTUQgaXMgYSBwb3Rl bnRpYWwgcm9vdCBkZXZpY2UNCm9wdGlvbnMgCU5GUwkJCSNOZXR3b3JrIEZp bGVzeXN0ZW0NCm9wdGlvbnMgCU5GU19ST09UCQkjTkZTIHVzYWJsZSBhcyBy b290IGRldmljZSwgTkZTIHJlcXVpcmVkDQpvcHRpb25zIAlNU0RPU0ZTCQkJ I01TRE9TIEZpbGVzeXN0ZW0NCm9wdGlvbnMgCUNEOTY2MAkJCSNJU08gOTY2 MCBGaWxlc3lzdGVtDQpvcHRpb25zIAlDRDk2NjBfUk9PVAkJI0NELVJPTSB1 c2FibGUgYXMgcm9vdCwgQ0Q5NjYwIHJlcXVpcmVkDQpvcHRpb25zIAlQUk9D RlMJCQkjUHJvY2VzcyBmaWxlc3lzdGVtDQpvcHRpb25zIAlDT01QQVRfNDMJ CSNDb21wYXRpYmxlIHdpdGggQlNEIDQuMyBbS0VFUCBUSElTIV0NCm9wdGlv bnMgCVNDU0lfREVMQVk9MTUwMDAJI0RlbGF5IChpbiBtcykgYmVmb3JlIHBy b2JpbmcgU0NTSQ0Kb3B0aW9ucyAJVUNPTlNPTEUJCSNBbGxvdyB1c2VycyB0 byBncmFiIHRoZSBjb25zb2xlDQpvcHRpb25zIAlVU0VSQ09ORklHCQkjYm9v dCAtYyBlZGl0b3INCm9wdGlvbnMgCVZJU1VBTF9VU0VSQ09ORklHCSN2aXN1 YWwgYm9vdCAtYyBlZGl0b3INCm9wdGlvbnMgCUtUUkFDRQkJCSNrdHJhY2Uo MSkgc3VwcG9ydA0Kb3B0aW9ucyAJU1lTVlNITQkJCSNTWVNWLXN0eWxlIHNo YXJlZCBtZW1vcnkNCm9wdGlvbnMgCVNZU1ZNU0cJCQkjU1lTVi1zdHlsZSBt ZXNzYWdlIHF1ZXVlcw0Kb3B0aW9ucyAJU1lTVlNFTQkJCSNTWVNWLXN0eWxl IHNlbWFwaG9yZXMNCm9wdGlvbnMgCVAxMDAzXzFCCQkjUG9zaXggUDEwMDNf MUIgcmVhbC10aW1lIGV4dGVuc2lvbnMNCm9wdGlvbnMgCV9LUE9TSVhfUFJJ T1JJVFlfU0NIRURVTElORw0Kb3B0aW9ucwkJSUNNUF9CQU5ETElNCQkjUmF0 ZSBsaW1pdCBiYWQgcmVwbGllcw0Kb3B0aW9ucyAJS0JEX0lOU1RBTExfQ0RF VgkjIGluc3RhbGwgYSBDREVWIGVudHJ5IGluIC9kZXYNCiNvcHRpb25zICAg ICAgICAgTkVUU01CICAgICAgICAgICAgICAgICAgI1NNQi9DSUZTIHJlcXVl c3Rlcg0KI29wdGlvbnMgICAgICAgICBORVRTTUJDUllQVE8gICAgICAgICAg ICAjZW5jcnlwdGVkIHBhc3N3b3JkIHN1cHBvcnQgZm9yIFNNQg0Kb3B0aW9u cyAgICAgICAgIFFVT1RBICAgICAgICAgICAgICAgICAgICNlbmFibGUgZGlz ayBxdW90YXMNCg0KZGV2aWNlCQlpc2ENCmRldmljZQkJZWlzYQ0KZGV2aWNl CQlwY2kNCg0KIyBGbG9wcHkgZHJpdmVzDQpkZXZpY2UJCWZkYzAJYXQgaXNh PyBwb3J0IElPX0ZEMSBpcnEgNiBkcnEgMg0KZGV2aWNlCQlmZDAJYXQgZmRj MCBkcml2ZSAwDQojZGV2aWNlCQlmZDEJYXQgZmRjMCBkcml2ZSAxDQojDQoj IElmIHlvdSBoYXZlIGEgVG9zaGliYSBMaWJyZXR0byB3aXRoIGl0cyBZLUUg RGF0YSBQQ01DSUEgZmxvcHB5LA0KIyBkb24ndCB1c2UgdGhlIGFib3ZlIGxp bmUgZm9yIGZkYzAgYnV0IHRoZSBmb2xsb3dpbmcgb25lOg0KI2RldmljZQkJ ZmRjMA0KDQojIEFUQSBhbmQgQVRBUEkgZGV2aWNlcw0KZGV2aWNlCQlhdGEw CWF0IGlzYT8gcG9ydCBJT19XRDEgaXJxIDE0DQpkZXZpY2UJCWF0YTEJYXQg aXNhPyBwb3J0IElPX1dEMiBpcnEgMTUNCmRldmljZQkJYXRhDQpkZXZpY2UJ CWF0YWRpc2sJCQkjIEFUQSBkaXNrIGRyaXZlcw0KZGV2aWNlCQlhdGFwaWNk CQkJIyBBVEFQSSBDRFJPTSBkcml2ZXMNCiNkZXZpY2UJCWF0YXBpZmQJCQkj IEFUQVBJIGZsb3BweSBkcml2ZXMNCiNkZXZpY2UJCWF0YXBpc3QJCQkjIEFU QVBJIHRhcGUgZHJpdmVzDQpvcHRpb25zIAlBVEFfU1RBVElDX0lECQkjU3Rh dGljIGRldmljZSBudW1iZXJpbmcNCg0KIyBTQ1NJIENvbnRyb2xsZXJzDQoj ZGV2aWNlCQlhaGIJCSMgRUlTQSBBSEExNzQyIGZhbWlseQ0KZGV2aWNlCQlh aGMJCSMgQUhBMjk0MCBhbmQgb25ib2FyZCBBSUM3eHh4IGRldmljZXMNCiNk ZXZpY2UJCWFtZAkJIyBBTUQgNTNDOTc0IChUZWtyYW0gREMtMzkwKFQpKQ0K I2RldmljZQkJaXNwCQkjIFFsb2dpYyBmYW1pbHkNCiNkZXZpY2UJCW5jcgkJ IyBOQ1IvU3ltYmlvcyBMb2dpYw0KI2RldmljZQkJc3ltCQkjIE5DUi9TeW1i aW9zIExvZ2ljIChuZXdlciBjaGlwc2V0cykNCiNvcHRpb25zCQlTWU1fU0VU VVBfTFBfUFJPQkVfTUFQPTB4NDANCgkJCQkjIEFsbG93IG5jciB0byBhdHRh Y2ggbGVnYWN5IE5DUiBkZXZpY2VzIHdoZW4gDQoJCQkJIyBib3RoIHN5bSBh bmQgbmNyIGFyZSBjb25maWd1cmVkDQoNCiNkZXZpY2UJCWFkdjAJYXQgaXNh Pw0KI2RldmljZQkJYWR3DQojZGV2aWNlCQlidDAJYXQgaXNhPw0KI2Rldmlj ZQkJYWhhMAlhdCBpc2E/DQojZGV2aWNlCQlhaWMwCWF0IGlzYT8NCg0KI2Rl dmljZQkJbmN2CQkjIE5DUiA1M0M1MDANCiNkZXZpY2UJCW5zcAkJIyBXb3Jr Yml0IE5pbmphIFNDU0ktMw0KI2RldmljZQkJc3RnCQkjIFRNQyAxOEMzMC8x OEM1MA0KDQojIFNDU0kgcGVyaXBoZXJhbHMNCmRldmljZQkJc2NidXMJCSMg U0NTSSBidXMgKHJlcXVpcmVkKQ0KZGV2aWNlCQlkYQkJIyBEaXJlY3QgQWNj ZXNzIChkaXNrcykNCmRldmljZQkJc2EJCSMgU2VxdWVudGlhbCBBY2Nlc3Mg KHRhcGUgZXRjKQ0KZGV2aWNlCQljZAkJIyBDRA0KZGV2aWNlCQlwYXNzCQkj IFBhc3N0aHJvdWdoIGRldmljZSAoZGlyZWN0IFNDU0kgYWNjZXNzKQ0KDQoj IFJBSUQgY29udHJvbGxlcnMgaW50ZXJmYWNlZCB0byB0aGUgU0NTSSBzdWJz eXN0ZW0NCiNkZXZpY2UJCWFzcgkJIyBEUFQgU21hcnRSQUlEIFYsIFZJIGFu ZCBBZGFwdGVjIFNDU0kgUkFJRA0KI2RldmljZQkJZHB0CQkjIERQVCBTbWFy dGNhY2hlIC0gU2VlIExJTlQgZm9yIG9wdGlvbnMhDQojZGV2aWNlICAgICAg ICAgaWlyICAgICAgICAgICAgICMgSW50ZWwgSW50ZWdyYXRlZCBSQUlEDQoj ZGV2aWNlCQltbHkJCSMgTXlsZXggQWNjZWxlUkFJRC9lWHRyZW1lUkFJRA0K I2RldmljZQkJY2lzcwkJIyBDb21wYXEgU21hcnRSQUlEIDUqIHNlcmllcw0K DQojIFJBSUQgY29udHJvbGxlcnMNCiNkZXZpY2UJCWFhYwkJIyBBZGFwdGVj IEZTQSBSQUlELCBEZWxsIFBFUkMyL1BFUkMzDQojZGV2aWNlCQlhYWNwCQkj IFNDU0kgcGFzc3Rocm91Z2ggZm9yIGFhYyAocmVxdWlyZXMgQ0FNKQ0KI2Rl dmljZQkJaWRhCQkjIENvbXBhcSBTbWFydCBSQUlEDQojZGV2aWNlCQlhbXIJ CSMgQU1JIE1lZ2FSQUlEDQojZGV2aWNlCQltbHgJCSMgTXlsZXggREFDOTYw IGZhbWlseQ0KI2RldmljZQkJdHdlCQkjIDN3YXJlIEVzY2FsYWRlDQoNCiMg YXRrYmRjMCBjb250cm9scyBib3RoIHRoZSBrZXlib2FyZCBhbmQgdGhlIFBT LzIgbW91c2UNCmRldmljZQkJYXRrYmRjMAlhdCBpc2E/IHBvcnQgSU9fS0JE DQpkZXZpY2UJCWF0a2JkMAlhdCBhdGtiZGM/IGlycSAxIA0KZGV2aWNlCQlw c20wCWF0IGF0a2JkYz8gaXJxIDEyDQoNCmRldmljZQkJdmdhMAlhdCBpc2E/ DQoNCiMgc3BsYXNoIHNjcmVlbi9zY3JlZW4gc2F2ZXINCnBzZXVkby1kZXZp Y2UJc3BsYXNoDQoNCiMgc3lzY29ucyBpcyB0aGUgZGVmYXVsdCBjb25zb2xl IGRyaXZlciwgcmVzZW1ibGluZyBhbiBTQ08gY29uc29sZQ0KZGV2aWNlCQlz YzAJYXQgaXNhPyBmbGFncyAweDEwMA0KDQojIEVuYWJsZSB0aGlzIGFuZCBQ Q1ZUX0ZSRUVCU0QgZm9yIHBjdnQgdnQyMjAgY29tcGF0aWJsZSBjb25zb2xl IGRyaXZlcg0KI2RldmljZQkJdnQwCWF0IGlzYT8NCiNvcHRpb25zIAlYU0VS VkVSCQkJIyBzdXBwb3J0IGZvciBYIHNlcnZlciBvbiBhIHZ0IGNvbnNvbGUN CiNvcHRpb25zIAlGQVRfQ1VSU09SCQkjIHN0YXJ0IHdpdGggYmxvY2sgY3Vy c29yDQojIElmIHlvdSBoYXZlIGEgVGhpbmtQQUQsIHVuY29tbWVudCB0aGlz IGFsb25nIHdpdGggdGhlIHJlc3Qgb2YgdGhlIFBDVlQgbGluZXMNCiNvcHRp b25zIAlQQ1ZUX1NDQU5TRVQ9MgkJIyBJQk0ga2V5Ym9hcmRzIGFyZSBub24t c3RkDQoNCiMgRmxvYXRpbmcgcG9pbnQgc3VwcG9ydCAtIGRvIG5vdCBkaXNh YmxlLg0KZGV2aWNlCQlucHgwCWF0IG5leHVzPyBwb3J0IElPX05QWCBpcnEg MTMNCg0KIyBQb3dlciBtYW5hZ2VtZW50IHN1cHBvcnQgKHNlZSBMSU5UIGZv ciBtb3JlIG9wdGlvbnMpDQpkZXZpY2UJCWFwbTAgICAgYXQgbmV4dXM/IGRp c2FibGUgZmxhZ3MgMHgyMCAjIEFkdmFuY2VkIFBvd2VyIE1hbmFnZW1lbnQN Cg0KIyBTZXJpYWwgKENPTSkgcG9ydHMNCmRldmljZQkJc2lvMAlhdCBpc2E/ IHBvcnQgSU9fQ09NMSBmbGFncyAweDMwIGlycSA0DQpkZXZpY2UJCXNpbzEJ YXQgaXNhPyBwb3J0IElPX0NPTTIgaXJxIDMNCiNkZXZpY2UJCXNpbzIJYXQg aXNhPyBkaXNhYmxlIHBvcnQgSU9fQ09NMyBpcnEgNQ0KI2RldmljZQkJc2lv MwlhdCBpc2E/IGRpc2FibGUgcG9ydCBJT19DT000IGlycSA5DQoNCiMgUGFy YWxsZWwgcG9ydA0KZGV2aWNlCQlwcGMwCWF0IGlzYT8gaXJxIDcNCmRldmlj ZQkJcHBidXMJCSMgUGFyYWxsZWwgcG9ydCBidXMgKHJlcXVpcmVkKQ0KZGV2 aWNlCQlscHQJCSMgUHJpbnRlcg0KI2RldmljZQkJcGxpcAkJIyBUQ1AvSVAg b3ZlciBwYXJhbGxlbA0KZGV2aWNlCQlwcGkJCSMgUGFyYWxsZWwgcG9ydCBp bnRlcmZhY2UgZGV2aWNlDQojZGV2aWNlCQl2cG8JCSMgUmVxdWlyZXMgc2Ni dXMgYW5kIGRhDQoNCg0KIyBQQ0kgRXRoZXJuZXQgTklDcy4NCiNkZXZpY2UJ CWRlCQkjIERFQy9JbnRlbCBEQzIxeDR4IChgYFR1bGlwJycpDQojZGV2aWNl CQl0eHAJCSMgM0NvbSAzY1I5OTAgKGBgVHlwaG9vbicnKQ0KI2RldmljZQkJ dngJCSMgM0NvbSAzYzU5MCwgM2M1OTUgKGBgVm9ydGV4JycpDQoNCiMgUENJ IEV0aGVybmV0IE5JQ3MgdGhhdCB1c2UgdGhlIGNvbW1vbiBNSUkgYnVzIGNv bnRyb2xsZXIgY29kZS4NCiMgTk9URTogQmUgc3VyZSB0byBrZWVwIHRoZSAn ZGV2aWNlIG1paWJ1cycgbGluZSBpbiBvcmRlciB0byB1c2UgdGhlc2UgTklD cyENCmRldmljZQkJbWlpYnVzCQkjIE1JSSBidXMgc3VwcG9ydA0KI2Rldmlj ZQkJZGMJCSMgREVDL0ludGVsIDIxMTQzIGFuZCB2YXJpb3VzIHdvcmthbGlr ZXMNCmRldmljZQkJZnhwCQkjIEludGVsIEV0aGVyRXhwcmVzcyBQUk8vMTAw QiAoODI1NTcsIDgyNTU4KQ0KI2RldmljZQkJcGNuCQkjIEFNRCBBbTc5Qzk3 eCBQQ0kgMTAvMTAwIE5JQ3MNCiNkZXZpY2UJCXJsCQkjIFJlYWxUZWsgODEy OS84MTM5DQojZGV2aWNlCQlzZgkJIyBBZGFwdGVjIEFJQy02OTE1IChgYFN0 YXJmaXJlJycpDQojZGV2aWNlCQlzaXMJCSMgU2lsaWNvbiBJbnRlZ3JhdGVk IFN5c3RlbXMgU2lTIDkwMC9TaVMgNzAxNg0KI2RldmljZQkJc3RlCQkjIFN1 bmRhbmNlIFNUMjAxIChELUxpbmsgREZFLTU1MFRYKQ0KI2RldmljZQkJdGwJ CSMgVGV4YXMgSW5zdHJ1bWVudHMgVGh1bmRlckxBTg0KI2RldmljZQkJdHgJ CSMgU01DIEV0aGVyUG93ZXIgSUkgKDgzYzE3MCBgYEVQSUMnJykNCiNkZXZp Y2UJCXZyCQkjIFZJQSBSaGluZSwgUmhpbmUgSUkNCiNkZXZpY2UJCXdiCQkj IFdpbmJvbmQgVzg5Qzg0MEYNCiNkZXZpY2UJCXd4CQkjIEludGVsIEdpZ2Fi aXQgRXRoZXJuZXQgQ2FyZCAoYGBXaXNlbWFuJycpDQojZGV2aWNlCQl4bAkJ IyAzQ29tIDNjOTB4IChgYEJvb21lcmFuZycnLCBgYEN5Y2xvbmUnJykNCiNk ZXZpY2UJCWJnZQkJIyBCcm9hZGNvbSBCQ001NzB4IChgYFRpZ29uIElJSScn KQ0KDQojIElTQSBFdGhlcm5ldCBOSUNzLg0KIyAnZGV2aWNlIGVkJyByZXF1 aXJlcyAnZGV2aWNlIG1paWJ1cycNCiNkZXZpY2UJCWVkMAlhdCBpc2E/IHBv cnQgMHgyODAgaXJxIDEwIGlvbWVtIDB4ZDgwMDANCiNkZXZpY2UJCWV4DQoj ZGV2aWNlCQllcA0KI2RldmljZQkJZmUwCWF0IGlzYT8gcG9ydCAweDMwMA0K IyBYaXJjb20gRXRoZXJuZXQNCiNkZXZpY2UJCXhlDQojIFBSSVNNIEkgSUVF RSA4MDIuMTFiIHdpcmVsZXNzIE5JQy4NCiNkZXZpY2UJCWF3aQ0KIyBXYXZl TEFOL0lFRUUgODAyLjExIHdpcmVsZXNzIE5JQ3MuIE5vdGU6IHRoZSBXYXZl TEFOL0lFRUUgcmVhbGx5DQojIGV4aXN0cyBvbmx5IGFzIGEgUENNQ0lBIGRl dmljZSwgc28gdGhlcmUgaXMgbm8gSVNBIGF0dGFjaG1lbnQgbmVlZGVkDQoj IGFuZCByZXNvdXJjZXMgd2lsbCBhbHdheXMgYmUgZHluYW1pY2FsbHkgYXNz aWduZWQgYnkgdGhlIHBjY2FyZCBjb2RlLg0KI2RldmljZQkJd2kNCiMgQWly b25ldCA0NTAwLzQ4MDAgODAyLjExIHdpcmVsZXNzIE5JQ3MuIE5vdGU6IHRo ZSBkZWNsYXJhdGlvbiBiZWxvdyB3aWxsDQojIHdvcmsgZm9yIFBDTUNJQSBh bmQgUENJIGNhcmRzLCBhcyB3ZWxsIGFzIElTQSBjYXJkcyBzZXQgdG8gSVNB IFBuUA0KIyBtb2RlICh0aGUgZmFjdG9yeSBkZWZhdWx0KS4gSWYgeW91IHNl dCB0aGUgc3dpdGNoZXMgb24geW91ciBJU0ENCiMgY2FyZCBmb3IgYSBtYW51 YWxseSBjaG9zZW4gSS9PIGFkZHJlc3MgYW5kIElSUSwgeW91IG11c3Qgc3Bl Y2lmeQ0KIyB0aG9zZSBwYXJhbWV0ZXJzIGhlcmUuDQojZGV2aWNlCQlhbg0K IyBUaGUgcHJvYmUgb3JkZXIgb2YgdGhlc2UgaXMgcHJlc2VudGx5IGRldGVy bWluZWQgYnkgaTM4Ni9pc2EvaXNhX2NvbXBhdC5jLg0KI2RldmljZQkJaWUw CWF0IGlzYT8gcG9ydCAweDMwMCBpcnEgMTAgaW9tZW0gMHhkMDAwMA0KI2Rl dmljZQkJbGUwCWF0IGlzYT8gcG9ydCAweDMwMCBpcnEgNSBpb21lbSAweGQw MDAwDQojZGV2aWNlCQlsbmMwCWF0IGlzYT8gcG9ydCAweDI4MCBpcnEgMTAg ZHJxIDANCiNkZXZpY2UJCWNzMAlhdCBpc2E/IHBvcnQgMHgzMDANCiNkZXZp Y2UJCXNuMAlhdCBpc2E/IHBvcnQgMHgzMDAgaXJxIDEwDQoNCiMgUHNldWRv IGRldmljZXMgLSB0aGUgbnVtYmVyIGluZGljYXRlcyBob3cgbWFueSB1bml0 cyB0byBhbGxvY2F0ZS4NCnBzZXVkby1kZXZpY2UJbG9vcAkJIyBOZXR3b3Jr IGxvb3BiYWNrDQpwc2V1ZG8tZGV2aWNlCWV0aGVyCQkjIEV0aGVybmV0IHN1 cHBvcnQNCiNwc2V1ZG8tZGV2aWNlCXNsCTEJIyBLZXJuZWwgU0xJUA0KcHNl dWRvLWRldmljZQlwcHAJMQkjIEtlcm5lbCBQUFANCnBzZXVkby1kZXZpY2UJ dHVuCQkjIFBhY2tldCB0dW5uZWwuDQpwc2V1ZG8tZGV2aWNlCXB0eQkJIyBQ c2V1ZG8tdHR5cyAodGVsbmV0IGV0YykNCnBzZXVkby1kZXZpY2UJbWQJCSMg TWVtb3J5ICJkaXNrcyINCiNwc2V1ZG8tZGV2aWNlCWdpZgkJIyBJUHY2IGFu ZCBJUHY0IHR1bm5lbGluZw0KI3BzZXVkby1kZXZpY2UJZmFpdGgJMQkjIElQ djYtdG8tSVB2NCByZWxheWluZyAodHJhbnNsYXRpb24pDQpwc2V1ZG8tZGV2 aWNlICAgdmxhbiAgICAyDQpvcHRpb25zICAgICAgICAgUFBQX0JTRENPTVAg ICAgICAgICAgICAgI1BQUCBCU0QtY29tcHJlc3Mgc3VwcG9ydA0Kb3B0aW9u cyAgICAgICAgIFBQUF9ERUZMQVRFICAgICAgICAgICAgICNQUFAgemxpYi9k ZWZsYXRlL2d6aXAgc3VwcG9ydA0Kb3B0aW9ucyAgICAgICAgIFBQUF9GSUxU RVIgICAgICAgICAgICAgICNlbmFibGUgYnBmIGZpbHRlcmluZyAobmVlZHMg YnBmKQ0KcHNldWRvLWRldmljZSAgIHNwZWFrZXINCnBzZXVkby1kZXZpY2Ug ICBnemlwDQpwc2V1ZG8tZGV2aWNlICAgdm4NCnBzZXVkby1kZXZpY2UgICBz bnANCiNwc2V1ZG8tZGV2aWNlICAgY3J5cHRvDQoNCiMgVGhlIGBicGYnIHBz ZXVkby1kZXZpY2UgZW5hYmxlcyB0aGUgQmVya2VsZXkgUGFja2V0IEZpbHRl ci4NCiMgQmUgYXdhcmUgb2YgdGhlIGFkbWluaXN0cmF0aXZlIGNvbnNlcXVl bmNlcyBvZiBlbmFibGluZyB0aGlzIQ0KcHNldWRvLWRldmljZQlicGYJCSNC ZXJrZWxleSBwYWNrZXQgZmlsdGVyDQoNCiMgVVNCIHN1cHBvcnQNCmRldmlj ZQkJdWhjaQkJIyBVSENJIFBDSS0+VVNCIGludGVyZmFjZQ0KI2RldmljZQkJ b2hjaQkJIyBPSENJIFBDSS0+VVNCIGludGVyZmFjZQ0KZGV2aWNlCQl1c2IJ CSMgVVNCIEJ1cyAocmVxdWlyZWQpDQpkZXZpY2UJCXVnZW4JCSMgR2VuZXJp Yw0KZGV2aWNlCQl1aGlkCQkjICJIdW1hbiBJbnRlcmZhY2UgRGV2aWNlcyIN CmRldmljZQkJdWtiZAkJIyBLZXlib2FyZA0KZGV2aWNlCQl1bHB0CQkjIFBy aW50ZXINCmRldmljZQkJdW1hc3MJCSMgRGlza3MvTWFzcyBzdG9yYWdlIC0g UmVxdWlyZXMgc2NidXMgYW5kIGRhDQpkZXZpY2UJCXVtcwkJIyBNb3VzZQ0K ZGV2aWNlCQl1c2Nhbm5lcgkjIFNjYW5uZXJzDQpkZXZpY2UJCXVyaW8JCSMg RGlhbW9uZCBSaW8gTVAzIFBsYXllcg0KIyBVU0IgRXRoZXJuZXQsIHJlcXVp cmVzIG1paQ0KI2RldmljZQkJYXVlCQkjIEFETXRlayBVU0IgZXRoZXJuZXQN CiNkZXZpY2UJCWN1ZQkJIyBDQVRDIFVTQiBldGhlcm5ldA0KI2RldmljZQkJ a3VlCQkjIEthd2FzYWtpIExTSSBVU0IgZXRoZXJuZXQNCg== --0-1073977242-1050184939=:40826-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 13 14:53:22 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A96E37B401; Sun, 13 Apr 2003 14:53:22 -0700 (PDT) Received: from amour.ath.cx (p62.246.200.221.tisdip.tiscali.de [62.246.200.221]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2963B43F75; Sun, 13 Apr 2003 14:53:21 -0700 (PDT) (envelope-from amour@amour.ath.cx) Received: from amour.ath.cx (amour@localhost.ath.cx [127.0.0.1]) by amour.ath.cx (8.12.9/8.12.9) with ESMTP id h3DLrJxU066168; Sun, 13 Apr 2003 23:53:19 +0200 (CEST) (envelope-from amour@amour.ath.cx) Received: from localhost (amour@localhost) by amour.ath.cx (8.12.9/8.12.9/Submit) with ESMTP id h3DLrIIB066165; Sun, 13 Apr 2003 23:53:19 +0200 (CEST) Date: Sun, 13 Apr 2003 23:53:18 +0200 (CEST) From: Alexander To: freebsd-questions@freebsd.org Message-ID: <20030413233019.S65387-100000@amour.ath.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-isp@freebsd.org cc: freebsd-net@freebsd.org Subject: "pipe sharing program", something like cbq X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2003 21:53:23 -0000 Hello ! I'm looking a program that can do the following stuff: If I have 5 clients, each of them with 64k pipe and all of them share a 256k pipe. And at a certain time some of the clients are using their full 64k capacity and the others are using not pretty much (like just browsing sites or just idling), so the program should notice that and get some from the 64k pipe of each idler and share it through the rest of active users. thanks P.S. Please include my email when replying, thanks From owner-freebsd-net@FreeBSD.ORG Sun Apr 13 15:04:33 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DB5237B401; Sun, 13 Apr 2003 15:04:33 -0700 (PDT) Received: from relay.boerde.de (relay.boerde.de [213.187.87.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B72B243FA3; Sun, 13 Apr 2003 15:04:32 -0700 (PDT) (envelope-from shauwn@relay.boerde.de) Received: by relay.boerde.de (Postfix, from userid 639) id 3AAE9139A3; Mon, 14 Apr 2003 00:04:31 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by relay.boerde.de (Postfix) with ESMTP id 2F51D139A1; Mon, 14 Apr 2003 00:04:31 +0200 (MEST) Date: Mon, 14 Apr 2003 00:04:31 +0200 (MEST) From: Frank Reppin To: Alexander In-Reply-To: <20030413233019.S65387-100000@amour.ath.cx> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-isp@freebsd.org cc: freebsd-net@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: "pipe sharing program", something like cbq X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Frank.Reppin@boerde.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2003 22:04:33 -0000 On Sun, 13 Apr 2003, Alexander wrote: > Hello ! hi, > > I'm looking a program that can do the following stuff: > > If I have 5 clients, each of them with 64k pipe and all of them share a > 256k pipe. And at a certain time some of the clients are using their full > 64k capacity and the others are using not pretty much (like just browsing > sites or just idling), so the program should notice that and get some from > the 64k pipe of each idler and share it through the rest of active users. ALTQD: http://www.csl.sony.co.jp/~kjc/software.html#ALTQ should fulfil your needs. You can define classes within CBQ and those classes can borrow 'unused' bandwidth from their respective parentclasses. Best regards, Frank Reppin From owner-freebsd-net@FreeBSD.ORG Sun Apr 13 15:08:17 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C23E37B401; Sun, 13 Apr 2003 15:08:17 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-63-207-60-150.dsl.lsan03.pacbell.net [63.207.60.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE3FE43FA3; Sun, 13 Apr 2003 15:08:16 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id AB1AB66CFB; Sun, 13 Apr 2003 15:08:16 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 8D2B9110C; Sun, 13 Apr 2003 15:08:16 -0700 (PDT) Date: Sun, 13 Apr 2003 15:08:16 -0700 From: Kris Kennaway To: current@FreeBSD.org, net@FreeBSD.org, hsu@FreeBSD.org Message-ID: <20030413220816.GA52457@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline User-Agent: Mutt/1.4i Subject: Deadlocks running rsync on SMP machine X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2003 22:08:17 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've been getting repeatable deadlocks when rsyncing a large set of files over a LAN on an SMP machine running -current (bento). The console does not respond to the debugger break, and I turned on WITNESS to see if that would catch it, but it did not. This has been going on for some weeks now; I guess I'll have to do a binary search to figure out the cutoff date. Prior to updating it I was getting a lot of double faults (already reported in another email a few days ago). This is very annoying and I wish someone would fix it :) I have to run 5.0 on bento because 4.x has fatal NFS bugs with sparc clients. Kris --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+md/QWry0BWjoQKURAjnAAJwM6QvFy11FXR/UAriH6L2Czoi1oACff9w/ TMWSMUDNYPGvcpbpuZJuW/k= =eKw4 -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 13 16:14:52 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 738AE37B401 for ; Sun, 13 Apr 2003 16:14:52 -0700 (PDT) Received: from mx2.nersc.gov (mx2.nersc.gov [128.55.6.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF44243F3F for ; Sun, 13 Apr 2003 16:14:51 -0700 (PDT) (envelope-from dart@nersc.gov) Received: from mx2.nersc.gov (localhost [127.0.0.1]) by localhost.nersc.gov (Postfix) with ESMTP id D72427786; Sun, 13 Apr 2003 16:14:50 -0700 (PDT) Received: from gemini.nersc.gov (gemini.nersc.gov [128.55.16.111]) by mx2.nersc.gov (Postfix) with ESMTP id 903C07785; Sun, 13 Apr 2003 16:14:48 -0700 (PDT) Received: from gemini.nersc.gov (localhost [127.0.0.1]) by gemini.nersc.gov (Postfix) with ESMTP id 91608327C0; Sun, 13 Apr 2003 16:14:47 -0700 (PDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Max Khon In-Reply-To: Message from Max Khon of "Fri, 11 Apr 2003 14:25:40 +0700." <20030411142540.A14117@iclub.nsu.ru> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_320516478P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 13 Apr 2003 16:14:47 -0700 From: Eli Dart Message-Id: <20030413231447.91608327C0@gemini.nersc.gov> cc: freebsd-net@freebsd.org Subject: Re: Bug in ARP requests X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2003 23:14:52 -0000 --==_Exmh_320516478P Content-Type: text/plain; charset=us-ascii In reply to Max Khon : > hi, there! > > ok, rev 1.97 MFC'ed a few minutes ago Is this going to make it into RELENG_4_8? I realize that this branch is mostly for security fixes, but there is some precedent for putting other bugfixes in the security branches when they affect core functionality... Thanks very much, --eli > > /fjoe > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --==_Exmh_320516478P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQE+me9nLTFEeF+CsrMRAkSJAJ9JT3phubP6NUoY0PK85M2kNDWFbQCfbMLM 2fOQAynuPUlrascDGACHGk4= =eyBq -----END PGP SIGNATURE----- --==_Exmh_320516478P-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 13 17:27:44 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A401F37B404 for ; Sun, 13 Apr 2003 17:27:44 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id C78A743FA3 for ; Sun, 13 Apr 2003 17:27:43 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 84464 invoked from network); 14 Apr 2003 00:27:42 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 14 Apr 2003 00:27:42 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 13 Apr 2003 14:23:54 -0500 (CDT) From: Mike Silbersack To: "M. Warner Losh" In-Reply-To: <20030412.212059.42399637.imp@bsdimp.com> Message-ID: <20030413142156.O44423@odysseus.silby.com> References: <109.225ca595.2bc723f2@aol.com> <20030412.204912.76964336.imp@bsdimp.com> <20030412.212059.42399637.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: barney@pit.databus.com cc: net@freebsd.org Subject: Re: connect(2) behavior with unreacheable hosts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2003 00:27:45 -0000 On Sat, 12 Apr 2003, M. Warner Losh wrote: > In message: <20030413030500.GA64896@pit.databus.com> > Barney Wolff writes: > : On Sat, Apr 12, 2003 at 08:49:12PM -0600, M. Warner Losh wrote: > : > In message: <109.225ca595.2bc723f2@aol.com> > : > BelletJr@aol.com writes: > : > : Why does not connect(2) return any error when trying to connect to a host > : > : unreachable because of an infinite loop in the routes? No time-out occurs and > : > : the value 0 is returned by connect(2). > : > > : > Hmmmmm, you are correct. I was sure that you were nuts, but on > : > -current the following program returns no error at all... Telnet > : > shows the same behavior. This is clearly wrong. > : > : It's not just current; stable behaves exactly the same. The problem is > : that the icmp time-exceeded packet gets translated into an error code > : of 0, which confuses things. I've filed a PR with a suggested fix: > : http://www.freebsd.org/cgi/query-pr.cgi?pr=50839 > > Ah. I see. I wonder if any of the net folks can review this... > > Warner EPLATEFULL, but it sounds correct... Barney, have you tried doing some sort of test where sendmail or ftpd tries making a connection to a TTL exceeded IP? I'm curious if they handle the situation gracefully or not. (If they don't, then maybe this is serious enough to require security branch merges.) Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Sun Apr 13 18:15:37 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52E8637B401 for ; Sun, 13 Apr 2003 18:15:37 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E01743FB1 for ; Sun, 13 Apr 2003 18:15:36 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9/8.12.9) with ESMTP id h3E1FVdN081198; Sun, 13 Apr 2003 21:15:31 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9/8.12.9/Submit) id h3E1FVh7081197; Sun, 13 Apr 2003 21:15:31 -0400 (EDT) Date: Sun, 13 Apr 2003 21:15:31 -0400 From: Barney Wolff To: Mike Silbersack Message-ID: <20030414011530.GA80964@pit.databus.com> References: <109.225ca595.2bc723f2@aol.com> <20030412.204912.76964336.imp@bsdimp.com> <20030413030500.GA64896@pit.databus.com> <20030412.212059.42399637.imp@bsdimp.com> <20030413142156.O44423@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030413142156.O44423@odysseus.silby.com> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) cc: barney@pit.databus.com cc: "M. Warner Losh" cc: net@freebsd.org Subject: Re: connect(2) behavior with unreacheable hosts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2003 01:15:37 -0000 On Sun, Apr 13, 2003 at 02:23:54PM -0500, Mike Silbersack wrote: > Barney, have you tried doing some sort of test where sendmail or ftpd > tries making a connection to a TTL exceeded IP? I'm curious if they > handle the situation gracefully or not. (If they don't, then maybe this > is serious enough to require security branch merges.) Here's ftp's behavior, first from an unpatched system: mob:/root# ftp 1.2.3.4 ftp: getsockname: Connection reset by peer ftp> quit mob:/root# ftp 1.2.3.5 ftp: connect: No route to host ftp> quit (1.2.3.4 is the looped address, and the getsockname comes back instantly, since the loop is over GigE. 1.2.3.5 times out before getting EHOSTUNREACH.) Here's the same on a patched system: lab:/home/barney $ ftp 1.2.3.4 ftp: connect: No route to host ftp> quit lab:/home/barney $ ftp 1.2.3.5 ftp: connect: Operation timed out ftp> quit Here are maillog entries, first from the unpatched system: Apr 13 20:58:26 mob sm-mta[76502]: h3E0wQZ3076500: to=, ctladdr= (202/1004), delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=30354, relay=bogus.no.such.domain. [1.2.3.4], dsn=4.0.0, stat=Deferred: Connection reset by bogus.no.such.domain. and the patched system: Apr 13 20:56:56 lab sm-mta[40480]: h3E0uunO040478: to=, ctladdr= (202/1004), delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=30355, relay=bogus.no.such.domain. [1.2.3.4], dsn=4.0.0, stat=Deferred: bogus.no.such.domain.: No route to host (In each case I put 1.2.3.4 bogus.no.such.domain in /etc/hosts.) Mike, I don't think this is a security issue - the client gets an instant SIGPIPE if it tries to write on the socket. I think telnet gets this. I did try traceroute, since it depends on time-exceeded. Worked fine. Barney -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Sun Apr 13 20:17:30 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BD0237B401; Sun, 13 Apr 2003 20:17:30 -0700 (PDT) Received: from ntli.com (pc1-glfd2-4-cust59.glfd.cable.ntl.com [81.99.187.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 074A043FA3; Sun, 13 Apr 2003 20:17:29 -0700 (PDT) (envelope-from william@palfreman.com) Received: from aqua.lan.palfreman.com (localhost [127.0.0.1]) by ntli.com (8.12.3p2/8.12.3) with ESMTP id h3E3OOuG057074; Mon, 14 Apr 2003 04:24:24 +0100 (BST) (envelope-from william@palfreman.com) Received: from localhost (william@localhost)h3E3ONeE057071; Mon, 14 Apr 2003 04:24:23 +0100 (BST) X-Authentication-Warning: aqua.lan.palfreman.com: william owned process doing -bs Date: Mon, 14 Apr 2003 04:24:23 +0100 (BST) From: William Palfreman To: questions@freebsd.org In-Reply-To: <20030411152659.U62406@ndhn.yna.cnyserzna.pbz> Message-ID: <20030414033701.P40826@ndhn.yna.cnyserzna.pbz> References: <20030411152659.U62406@ndhn.yna.cnyserzna.pbz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: users@freenet6.net cc: net@freebsd.org Subject: FIXED Re: Freenet6: spreading IPv6 addresses to the LAN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2003 03:17:30 -0000 On Sat, 12 Apr 2003, William Palfreman wrote: > What I would like to do now is use autoconfiguration to allocate ipv6 > addresses to other [FreeBSD] hosts on the lan. It isn't happening. Not that anyone replied, but I fixed this after hunting around for about the last four days. It was very simple. I needed to specify an inet6 address for the internal interface on the firewall (the prefixlen of /64 is the default), and to run rtadvd rl0 # rtadvd -d rl0 # ifconfig rl0 inet6 3ffe:b80:1d82:2::1 and on the hosts I needed to add "ipv6_enable="YES" to /etc/rc.conf Entering "sysctl -w net.inet6.ip6.accept_rtadv=1" has the same effect, but obviously putting ipv6_enable="YES" into rc.conf keeps it that way by default. I think this could really use being in the handbook. I suppose the right thing for me to do is email the author at the top of the page with an html patch. William. -- W. Palfreman. I'm looking for a job. Read my CV at: Tel: 0771 355 0354 www.palfreman.com/william/cv-wfp2.html From owner-freebsd-net@FreeBSD.ORG Sun Apr 13 23:45:42 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 880D837B40A for ; Sun, 13 Apr 2003 23:45:42 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id BAA6643FA3 for ; Sun, 13 Apr 2003 23:45:41 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 30181 invoked from network); 14 Apr 2003 06:45:40 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 14 Apr 2003 06:45:40 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 13 Apr 2003 20:41:51 -0500 (CDT) From: Mike Silbersack To: Barney Wolff In-Reply-To: <20030414011530.GA80964@pit.databus.com> Message-ID: <20030413203958.I93049@odysseus.silby.com> References: <109.225ca595.2bc723f2@aol.com> <20030412.204912.76964336.imp@bsdimp.com> <20030412.212059.42399637.imp@bsdimp.com> <20030414011530.GA80964@pit.databus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "M. Warner Losh" cc: net@freebsd.org Subject: Re: connect(2) behavior with unreacheable hosts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2003 06:45:42 -0000 On Sun, 13 Apr 2003, Barney Wolff wrote: > Mike, I don't think this is a security issue - the client gets an instant > SIGPIPE if it tries to write on the socket. I think telnet gets this. > > I did try traceroute, since it depends on time-exceeded. Worked fine. > Barney > > -- > Barney Wolff http://www.databus.com/bwresume.pdf Ok, so any properly written application will handle the case without issue, that's what I was curious about. I'll _try_ to get to committing the patch, but it'll be a few days at the minimum. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 12:01:57 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFD5F37B408 for ; Mon, 14 Apr 2003 12:01:57 -0700 (PDT) Received: from musique.teaser.net (musique.teaser.net [213.91.2.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30F6443FD7 for ; Mon, 14 Apr 2003 12:01:56 -0700 (PDT) (envelope-from e-masson@kisoft-services.com) Received: from notbsdems.interne.kisoft-services.com (d41-166.ppp.teaser.fr [213.91.41.166]) by musique.teaser.net (Postfix) with ESMTP id 2C51772506; Mon, 14 Apr 2003 21:01:52 +0200 (CEST) Received: by notbsdems.interne.kisoft-services.com (Postfix, from userid 1001) id B47815BC81; Mon, 14 Apr 2003 11:50:37 +0200 (CEST) To: Willie Viljoen From: Eric Masson In-Reply-To: <200304091616.18432.will@unfoldings.net> (Willie Viljoen's message of "Wed, 9 Apr 2003 16:16:18 +0200") References: <86znmzvkxc.fsf@notbsdems.interne.kisoft-services.com> <200304091616.18432.will@unfoldings.net> X-Operating-System: FreeBSD 4.8-RC i386 Date: Mon, 14 Apr 2003 11:50:37 +0200 Message-ID: <86smsltnki.fsf@notbsdems.interne.kisoft-services.com> User-Agent: Gnus/5.090018 (Oort Gnus v0.18) XEmacs/21.4 (Common Lisp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: Mailing List FreeBSD Network Subject: Re: mpd & nullmodem link X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2003 19:01:58 -0000 >>>>> "Willie" == Willie Viljoen writes: Hello, Willie> Why use mpd for this? Just because mpd is already on the box and not pppd (embedded machine) ;) Thanks for your pppd setup, it will probably help me with another couple of boxes. Regards. Eric Masson -- le seul moyen pour ne pas etre "rattrapé" par des aneries qu'on a dites c'est de ne pas dire d'anerie ce qui au bout du compte serait tout bénef pour usenet, mais ce média perdrait alors beaucoup de son attrait -+- JFP in - L'âne à Lise - From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 13:23:39 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E128937B401 for ; Mon, 14 Apr 2003 13:23:39 -0700 (PDT) Received: from usc.edu (usc.edu [128.125.253.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69E2A43FA3 for ; Mon, 14 Apr 2003 13:23:39 -0700 (PDT) (envelope-from kunchanl@pollux.usc.edu) Received: from pollux.usc.edu (kunchanl@pollux.usc.edu [128.125.7.29]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA02803 for ; Mon, 14 Apr 2003 13:23:38 -0700 (PDT) Received: from localhost (kunchanl@localhost) by pollux.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA16959 for ; Mon, 14 Apr 2003 13:23:38 -0700 (PDT) Date: Mon, 14 Apr 2003 13:23:38 -0700 (PDT) From: kunchanl To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: set gigabit card to lower speed on FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2003 20:23:40 -0000 Hi all, Do any of you know how I can force my Netgear GA620 gigabit ethernet card to run at lower speed (eg. 100BT) on freebsd from ifconfig, it seems I can only set the card in 1000baseSX mode vin# ifconfig -m ti0 ti0: flags=8843 mtu 1500 options=13 capability list: =13 inet6 fe80::2a0:ccff:fe73:3523%ti0 prefixlen 64 scopeid 0x4 inet 192.168.0.1 netmask 0xfffff000 broadcast 192.168.15.255 ether 00:a0:cc:73:35:23 media: Ethernet 1000baseSX (autoselect) status: no carrier supported media: media autoselect media 1000baseSX mediaopt full-duplex media 1000baseSX Thanks Kun-chan From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 13:39:50 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E056137B401 for ; Mon, 14 Apr 2003 13:39:50 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B49843F75 for ; Mon, 14 Apr 2003 13:39:50 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h3EKdkTk012409; Mon, 14 Apr 2003 13:39:46 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h3EKdkWE012408; Mon, 14 Apr 2003 13:39:46 -0700 Date: Mon, 14 Apr 2003 13:39:46 -0700 From: Brooks Davis To: kunchanl Message-ID: <20030414203945.GA9319@Odin.AC.HMC.Edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: freebsd-net@freebsd.org Subject: Re: set gigabit card to lower speed on FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2003 20:39:51 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 14, 2003 at 01:23:38PM -0700, kunchanl wrote: > Hi all, >=20 > Do any of you know how I can force my Netgear GA620 > gigabit ethernet card > to run at lower speed (eg. 100BT) on freebsd >=20 > from ifconfig, it seems I can only set the > card in 1000baseSX mode This device can't support other modes. In general fiber gigabit adaptors only support gigabit speeds. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+mxyRXY6L6fI4GtQRAmY7AKC2c0SO/VLTIN/f88yn/exPcob6igCgwRb9 GoBXZcPJUqpjrbsyM9DsXk8= =2H7+ -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 13:49:42 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 371B937B401 for ; Mon, 14 Apr 2003 13:49:42 -0700 (PDT) Received: from mail.redlinenetworks.com (mail.redlinenetworks.com [216.136.145.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id B89F043FAF for ; Mon, 14 Apr 2003 13:49:41 -0700 (PDT) (envelope-from sreekanth@redlinenetworks.com) Received: from SREELAPTOP (dhcp-174.redlinenetworks.com [192.168.40.174]) h3EKnfM14065; Mon, 14 Apr 2003 13:49:41 -0700 (PDT) (envelope-from sreekanth@redlinenetworks.com) From: "Sreekanth" To: "'Brooks Davis'" , "'kunchanl'" Date: Mon, 14 Apr 2003 13:49:44 -0700 Message-ID: <000e01c302c7$61493140$ae28a8c0@SREELAPTOP> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <20030414203945.GA9319@Odin.AC.HMC.Edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal cc: freebsd-net@freebsd.org Subject: RE: set gigabit card to lower speed on FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2003 20:49:42 -0000 > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Brooks Davis > Sent: Monday, April 14, 2003 1:40 PM > To: kunchanl > Cc: freebsd-net@freebsd.org > Subject: Re: set gigabit card to lower speed on FreeBSD > > > On Mon, Apr 14, 2003 at 01:23:38PM -0700, kunchanl wrote: > > Hi all, > > > > Do any of you know how I can force my Netgear GA620 > > gigabit ethernet card > > to run at lower speed (eg. 100BT) on freebsd > > > > from ifconfig, it seems I can only set the > > card in 1000baseSX mode > > This device can't support other modes. In general fiber > gigabit adaptors only support gigabit speeds Gigabit "fiber" adapters. Sreekanth > > -- Brooks > > -- > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 > From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 22:47:33 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E88B37B401 for ; Mon, 14 Apr 2003 22:47:33 -0700 (PDT) Received: from freebsd.giovannelli.com (freebsd.giovannelli.com [194.184.65.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4216843F3F for ; Mon, 14 Apr 2003 22:47:31 -0700 (PDT) (envelope-from gmarco@giovannelli.it) Received: from usul.giovannelli.it (usul.giovannelli.com [10.254.254.4]) h3F5kI2I031331 for ; Tue, 15 Apr 2003 07:46:19 +0200 (CEST) (envelope-from gmarco@giovannelli.it) Message-Id: <5.2.1.1.2.20030415070820.04610eb0@194.184.65.4> X-Sender: gmarco@194.184.65.4 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 15 Apr 2003 07:49:08 +0200 To: net@freebsd.org From: Gianmarco Giovannelli Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: mpd: PPTP call failed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2003 05:47:33 -0000 Hi I have a very strange problem with mpd which I am really not able to understand. I copied and adapted the config files from other two working bsd boxes but I am not able to let them work in this situation. Could be a problem of the carrier which could block some type of protocols ? The problem is this on both side: [vpn] device is now in state DOWN [vpn] device: OPEN event in state DOWN bind: Can't assign requested address [vpn] PPTP call failed [vpn] device is now in state OPENING [vpn] device: DOWN event in state OPENING [vpn] device is now in state DOWN [vpn] link: DOWN event [vpn] LCP: Down event [vpn] device: OPEN event in state DOWN The common env is this: FreeBSD box 4.8-STABLE of 10-04-2003 mpd-3.13 cvsupped and compiled yesterday both the box are behind a zyxel 645 dsl router which is doing a complete nat from it's public IP to the FreeBSD box. Box 1 name Euro ########################################################################### rl0: flags=8843 mtu 1500 inet 10.0.0.254 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:40:f4:72:27:2a media: Ethernet autoselect (100baseTX ) status: active rl1: flags=8843 mtu 1500 inet 10.0.1.1 netmask 0xffffff00 broadcast 10.0.1.255 ether 00:30:18:51:98:f8 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 rl0 is the internal one rl1 is the ethernet that talks with the router and which receive the nat of the public IP. freebsd:/home/gmarco# ipfw list 00050 divert 8668 ip from any to any via rl1 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 65000 allow ip from any to any 65535 deny ip from any to any freebsd:/home/gmarco# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.1.254 UGSc 5 21650 rl1 10/24 link#1 UC 0 0 rl0 10.0.1/24 link#2 UC 1 0 rl1 10.0.1.254 00:a0:c5:36:1a:b8 UHLW 6 360 rl1 911 127.0.0.1 127.0.0.1 UH 1 175 lo0 freebsd:/home/gmarco# less /usr/local/etc/mpd/mpd.conf default: load vpn vpn: new -i ng0 vpn vpn set debug 5 set iface disable on-demand set iface addrs 10.0.0.254 180.21.100.250 set iface idle 0 set iface route 180.21.100.250/24 set bundle disable multilink set bundle authname "user1 set bundle password "user1pwd" set link yes acfcomp protocomp set link no pap set link yes chap set link keep-alive 10 75 set ipcp yes vjcomp set ipcp ranges 10.0.0.254/32 180.21.100.250/32 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set bundle enable crypt-reqd set ccp yes mpp-stateless open freebsd:/home/gmarco# less /usr/local/etc/mpd/mpd.links # # For our PPTP server # vpn: set link type pptp set pptp enable originate incoming outcall set pptp self 81.75.144.245 set pptp peer 81.75.149.31 Box 2 name Service ########################################################################### rl0: flags=8843 mtu 1500 inet 180.21.100.250 netmask 0xfffff000 broadcast 180.21.111.255 ether 00:40:f4:72:28:3b media: Ethernet autoselect (10baseT/UTP) status: active rl1: flags=8843 mtu 1500 inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:30:18:51:79:f0 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 rl0 is the internal one rl1 is the ethernet that talks with the router and which receive the nat of the public IP. freebsd:/home/gmarco# ipfw list 00050 divert 8668 ip from any to any via rl1 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 65000 allow ip from any to any 65535 deny ip from any to any freebsd:/home/gmarco# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.1 UGSc 3 182 rl1 127.0.0.1 127.0.0.1 UH 1 149 lo0 180.21.96/20 link#1 UC 0 0 rl0 192.168.1 link#2 UC 1 0 rl1 192.168.1.1 00:a0:c5:34:e3:1a UHLW 4 490 rl1 1063 freebsd:/home/gmarco# cat /usr/local/etc/mpd/mpd.conf default: load vpn vpn: new -i ng0 vpn vpn set iface disable on-demand set debug 5 set iface addrs 180.21.100.250 10.0.0.254 set iface idle 0 set iface route 10.0.0.1/24 set bundle disable multilink set bundle authname "user1 set bundle password "user1pwd" set link yes acfcomp protocomp set link no pap set link yes chap set link keep-alive 10 75 set ipcp yes vjcomp set ipcp ranges 180.21.100.250/32 10.0.0.254/32 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set bundle enable crypt-reqd set ccp yes mpp-stateless open freebsd:/home/gmarco# cat /usr/local/etc/mpd/mpd.links # # For our PPTP server # vpn: set link type pptp set pptp self 81.75.149.31 set pptp peer 81.75.144.245 set pptp enable originate incoming outcall Thanks for attention and for any kind of help.... Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.gufi.org/~gmarco From owner-freebsd-net@FreeBSD.ORG Mon Apr 14 23:04:52 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 155D837B401 for ; Mon, 14 Apr 2003 23:04:52 -0700 (PDT) Received: from cecov.masternet.it (cecov.masternet.it [194.184.65.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCAC543F3F for ; Mon, 14 Apr 2003 23:04:50 -0700 (PDT) (envelope-from gmarco@scotty.masternet.it) Received: from usul.scotty.masternet.it (freebsd.giovannelli.com [194.184.65.139]) by cecov.masternet.it (8.12.9/8.12.9) with ESMTP id h3F661e6014542 for ; Tue, 15 Apr 2003 08:06:01 +0200 (CEST) (envelope-from gmarco@scotty.masternet.it) Message-Id: <5.2.1.1.2.20030415080605.022fc0e8@194.184.65.7> X-Sender: gmarco@194.184.65.7 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 15 Apr 2003 08:06:23 +0200 To: net@freebsd.org From: Gianmarco Giovannelli In-Reply-To: <5.2.1.1.2.20030415070820.04610eb0@194.184.65.4> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: mpd: PPTP call failed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2003 06:04:52 -0000 At 15/04/2003, you wrote: >Hi I have a very strange problem with mpd which I am really not able to >understand. >I copied and adapted the config files from other two working bsd boxes but >I am not able to let them work in this situation. > >Could be a problem of the carrier which could block some type of protocols ? I have to add that the other two working boxes are in a little different configuration. One box is fully natted behind another 645R router which maps all its port on the FreeBSD box, the other one is running PPPoE with user PPP so there is no nat on the public IP.... So could my problem related to the fact that Zyxel 645R (in the "problem" situation it is on both side of the vpn) is not able to fully map protocol/port on the FreeBSD box behind it ? Thanks.... Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.gufi.org/~gmarco From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 13:59:54 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7436237B40B for ; Tue, 15 Apr 2003 13:59:54 -0700 (PDT) Received: from web21009.mail.yahoo.com (web21009.mail.yahoo.com [216.136.227.63]) by mx1.FreeBSD.org (Postfix) with SMTP id 01A9B43F93 for ; Tue, 15 Apr 2003 13:59:54 -0700 (PDT) (envelope-from davidmyer800@yahoo.com) Message-ID: <20030415205953.98215.qmail@web21009.mail.yahoo.com> Received: from [65.172.158.93] by web21009.mail.yahoo.com via HTTP; Tue, 15 Apr 2003 13:59:53 PDT Date: Tue, 15 Apr 2003 13:59:53 -0700 (PDT) From: David Myer To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: socket API on loopback X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2003 20:59:54 -0000 Just wondering if the socket APIs ( socket, bind,connect.. ) work on the loopback interfave ? If not, what will be the error ?ThanksDave --------------------------------- Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 14:32:30 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F06237B401 for ; Tue, 15 Apr 2003 14:32:30 -0700 (PDT) Received: from overlord.e-gerbil.net (e-gerbil.net [69.31.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15BA143FAF for ; Tue, 15 Apr 2003 14:32:29 -0700 (PDT) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (ras@e-gerbil.net [69.31.1.2]) by overlord.e-gerbil.net (8.12.8/8.12.6) with ESMTP id h3FLWSXY042392; Tue, 15 Apr 2003 17:32:28 -0400 (EDT) (envelope-from ras@overlord.e-gerbil.net) Received: (from ras@localhost) by overlord.e-gerbil.net (8.12.8/8.12.6/Submit) id h3FLWShO042391; Tue, 15 Apr 2003 17:32:28 -0400 (EDT) (envelope-from ras) Date: Tue, 15 Apr 2003 17:32:27 -0400 From: Richard A Steenbergen To: David Myer Message-ID: <20030415213227.GL41027@overlord.e-gerbil.net> References: <20030415205953.98215.qmail@web21009.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030415205953.98215.qmail@web21009.mail.yahoo.com> User-Agent: Mutt/1.5.1i cc: net@freebsd.org Subject: Re: socket API on loopback X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2003 21:32:30 -0000 On Tue, Apr 15, 2003 at 01:59:53PM -0700, David Myer wrote: > Just wondering if the socket APIs ( socket, bind,connect.. ) work on the > loopback interfave ? If not, what will be the error ?ThanksDave Why wouldn't they? Many programs bind to 127.0.0.1 for internal use only. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 14:58:47 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 857E837B401 for ; Tue, 15 Apr 2003 14:58:47 -0700 (PDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5507343F75 for ; Tue, 15 Apr 2003 14:58:46 -0700 (PDT) (envelope-from damian@sentex.net) Received: from pegmatite.sentex.ca (pegmatite.sentex.ca [192.168.42.92]) by lava.sentex.ca (8.12.9/8.12.8) with ESMTP id h3FLwjME080390 for ; Tue, 15 Apr 2003 17:58:45 -0400 (EDT) (envelope-from damian@sentex.net) Received: by pegmatite.sentex.ca (Postfix, from userid 1001) id E8BC3170EC; Tue, 15 Apr 2003 17:58:44 -0400 (EDT) Date: Tue, 15 Apr 2003 17:58:44 -0400 From: Damian Gerow To: net@freebsd.org Message-ID: <20030415215844.GY648@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i X-Virus-Scanned: By Sentex Communications (lava/20020517) Subject: IPSec tunnel setup problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2003 21:58:47 -0000 Tried sending this to -questions, now trying -net. I'm pretty sure it's something obvious I'm missing, just don't know what. ----- I'm trying to set up an IPSec tunnel between two gateways, with little luck. I'm pretty sure I have my setkey entries done properly, it seems to be the negotiations that are failing. Local is 10.0.1.1, and remote is 10.0.2.1. Their is only a tunnel between the two remote LANs, there's no transport encryption. >From the initiating side, I see (roughly): 2003-04-04 15:33:19: DEBUG: remoteconf.c:118:getrmconf(): configuration found for 10.0.2.1 2003-04-04 15:33:19: INFO: isakmp.c:1684:isakmp_post_acquire(): IPsec-SA request for 10.0.2.1 queued due to no phase1 found. 2003-04-04 15:33:20: DEBUG: isakmp_agg.c:162:agg_i1send(): authmethod is pre-shared key 2003-04-04 15:33:20: DEBUG: isakmp.c:2113:set_isakmp_payload(): add payload of len 52, next type 4 2003-04-04 15:33:20: DEBUG: isakmp.c:2113:set_isakmp_payload(): add payload of len 192, next type 10 2003-04-04 15:33:20: DEBUG: isakmp.c:2113:set_isakmp_payload(): add payload of len 16, next type 5 2003-04-04 15:33:20: DEBUG: isakmp.c:2113:set_isakmp_payload(): add payload of len 8, next type 0 2003-04-04 15:33:20: DEBUG: isakmp.c:2248:isakmp_printpacket(): begin. 2003-04-04 15:33:20: DEBUG: sockmisc.c:421:sendfromto(): sockname 10.0.1.1[500] 2003-04-04 15:33:20: DEBUG: sockmisc.c:423:sendfromto(): send packet from 10.0.1.1[500] 2003-04-04 15:33:20: DEBUG: sockmisc.c:425:sendfromto(): send packet to 10.0.2.1[500] 2003-04-04 15:33:20: DEBUG: sockmisc.c:570:sendfromto(): 1 times of 312 bytes message will be sent to 10.0.1.1[500] 2003-04-04 15:33:20: DEBUG: isakmp.c:1449:isakmp_ph1resend(): resend phase1 packet d7824158efb89160:0000000000000000 So it /looks/ to be initiating correctly, no? The only thing that confuses me is that 10.0.1.1 is sending to 10.0.1.1, according to the debug output... I believe the problem is with the remote end: 2003-04-04 15:36:23: DEBUG: isakmp.c:222:isakmp_handler(): 312 bytes message received from 10.0.1.1[40418] 2003-04-04 15:36:23: DEBUG: isakmp.c:2248:isakmp_printpacket(): begin. 2003-04-04 15:36:23: DEBUG: remoteconf.c:134:getrmconf(): no remote configuration found. 2003-04-04 15:36:23: ERROR: isakmp.c:851:isakmp_ph1begin_r(): couldn't find configuration. So it looks like the remote racoon.conf isn't finding the 'remote 10.0.1.1' section, as it's failing in Phase I (Phase II would mean it can't find 'sainfo ...', right?). The two psk.txt's are exactly the same, the two /etc/ipsec.conf's are exact mirrors, and the two racoon.conf's are mirrors (with configuration names changed to match directions). It /feels/ like the remote (10.0.2.1) isn't finding the 'remote 10.0.1.1' configuration section that exists in there. I yanked the 'remote anonymous' and 'sainfo anonymous' configurations to help narrow this down. Does anyone have any pointers? Please reply personally, as I'm not subscribed. - Damian From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 15:03:19 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D127D37B401 for ; Tue, 15 Apr 2003 15:03:19 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 714E643F75 for ; Tue, 15 Apr 2003 15:03:14 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) h3FM3AhJ059301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Apr 2003 01:03:10 +0300 (EEST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9/8.12.8/Submit) id h3FM3ABM059296; Wed, 16 Apr 2003 01:03:10 +0300 (EEST) (envelope-from ru) Date: Wed, 16 Apr 2003 01:03:10 +0300 From: Ruslan Ermilov To: Damian Gerow Message-ID: <20030415220310.GB57610@sunbay.com> References: <20030415215844.GY648@sentex.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E39vaYmALEf/7YXx" Content-Disposition: inline In-Reply-To: <20030415215844.GY648@sentex.net> User-Agent: Mutt/1.5.4i cc: net@freebsd.org Subject: Re: IPSec tunnel setup problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2003 22:03:20 -0000 --E39vaYmALEf/7YXx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 15, 2003 at 05:58:44PM -0400, Damian Gerow wrote: > Tried sending this to -questions, now trying -net. I'm pretty sure it's > something obvious I'm missing, just don't know what. >=20 > ----- >=20 > I'm trying to set up an IPSec tunnel between two gateways, with little lu= ck. > I'm pretty sure I have my setkey entries done properly, it seems to be the > negotiations that are failing. Local is 10.0.1.1, and remote is 10.0.2.1. > Their is only a tunnel between the two remote LANs, there's no transport > encryption. >=20 > >From the initiating side, I see (roughly): >=20 > 2003-04-04 15:33:19: DEBUG: remoteconf.c:118:getrmconf(): configuration f= ound for 10.0.2.1 > 2003-04-04 15:33:19: INFO: isakmp.c:1684:isakmp_post_acquire(): IPsec-SA = request for 10.0.2.1 queued due to no phase1 found. > > 2003-04-04 15:33:20: DEBUG: isakmp_agg.c:162:agg_i1send(): authmethod is = pre-shared key > 2003-04-04 15:33:20: DEBUG: isakmp.c:2113:set_isakmp_payload(): add paylo= ad of len 52, next type 4 > 2003-04-04 15:33:20: DEBUG: isakmp.c:2113:set_isakmp_payload(): add paylo= ad of len 192, next type 10 > 2003-04-04 15:33:20: DEBUG: isakmp.c:2113:set_isakmp_payload(): add paylo= ad of len 16, next type 5 > 2003-04-04 15:33:20: DEBUG: isakmp.c:2113:set_isakmp_payload(): add paylo= ad of len 8, next type 0 > 2003-04-04 15:33:20: DEBUG: isakmp.c:2248:isakmp_printpacket(): begin. > > 2003-04-04 15:33:20: DEBUG: sockmisc.c:421:sendfromto(): sockname 10.0.1.= 1[500] > 2003-04-04 15:33:20: DEBUG: sockmisc.c:423:sendfromto(): send packet from= 10.0.1.1[500] > 2003-04-04 15:33:20: DEBUG: sockmisc.c:425:sendfromto(): send packet to 1= 0.0.2.1[500] > 2003-04-04 15:33:20: DEBUG: sockmisc.c:570:sendfromto(): 1 times of 312 b= ytes message will be sent to 10.0.1.1[500] > > 2003-04-04 15:33:20: DEBUG: isakmp.c:1449:isakmp_ph1resend(): resend phas= e1 packet d7824158efb89160:0000000000000000 >=20 > So it /looks/ to be initiating correctly, no? The only thing that confus= es > me is that 10.0.1.1 is sending to 10.0.1.1, according to the debug > output... >=20 > I believe the problem is with the remote end: >=20 > 2003-04-04 15:36:23: DEBUG: isakmp.c:222:isakmp_handler(): 312 bytes mess= age received from 10.0.1.1[40418] > > 2003-04-04 15:36:23: DEBUG: isakmp.c:2248:isakmp_printpacket(): begin. > > 2003-04-04 15:36:23: DEBUG: remoteconf.c:134:getrmconf(): no remote confi= guration found. > 2003-04-04 15:36:23: ERROR: isakmp.c:851:isakmp_ph1begin_r(): couldn't fi= nd configuration. >=20 > So it looks like the remote racoon.conf isn't finding the 'remote 10.0.1.= 1' > section, as it's failing in Phase I (Phase II would mean it can't find > 'sainfo ...', right?). >=20 > The two psk.txt's are exactly the same, the two /etc/ipsec.conf's are > exact mirrors, and the two racoon.conf's are mirrors (with configuration > names changed to match directions). It /feels/ like the remote (10.0.2.1) > isn't finding the 'remote 10.0.1.1' configuration section that exists in > there. I yanked the 'remote anonymous' and 'sainfo anonymous' > configurations to help narrow this down. >=20 > Does anyone have any pointers? Please reply personally, as I'm not > subscribed. >=20 Hmm, on my machines with IPSec tunnels the /etc/ipsec.conf's are NOT the exact mirrors; they are mirrors except for the in/out keywords. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --E39vaYmALEf/7YXx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD4DBQE+nIGeUkv4P6juNwoRAiAyAKCKl9te456p24fKpDiaQeWt3TdLZQCRAdtv hHkkSIAZoB18LZPCnX01gg== =RuoV -----END PGP SIGNATURE----- --E39vaYmALEf/7YXx-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 15:37:15 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B5CF37B401; Tue, 15 Apr 2003 15:37:15 -0700 (PDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F7D543FA3; Tue, 15 Apr 2003 15:37:14 -0700 (PDT) (envelope-from damian@sentex.net) Received: from pegmatite.sentex.ca (pegmatite.sentex.ca [192.168.42.92]) by lava.sentex.ca (8.12.9/8.12.8) with ESMTP id h3FMbEME080539; Tue, 15 Apr 2003 18:37:14 -0400 (EDT) (envelope-from damian@sentex.net) Received: by pegmatite.sentex.ca (Postfix, from userid 1001) id 4DA28170EC; Tue, 15 Apr 2003 18:37:13 -0400 (EDT) Date: Tue, 15 Apr 2003 18:37:13 -0400 From: Damian Gerow To: Ruslan Ermilov Message-ID: <20030415223713.GB648@sentex.net> References: <20030415215844.GY648@sentex.net> <20030415220310.GB57610@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030415220310.GB57610@sunbay.com> X-Operating-System: FreeBSD 5.0-CURRENT on a i386 X-GPG-Key: https://ssl3.sentex.ca/~damian/damian.asc X-GPG-Key-Id: 0xB841F142 X-GPG-Fingerprint: C7C1 E1D1 EC06 7C86 AF7C 57E6 173D 9CF6 B841 F142 User-Agent: Mutt/1.5.3i X-Virus-Scanned: By Sentex Communications (lava/20020517) cc: net@freebsd.org Subject: Re: IPSec tunnel setup problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2003 22:37:15 -0000 Thus spake Ruslan Ermilov (ru@freebsd.org) [15/04/03 18:04]: > > The two psk.txt's are exactly the same, the two /etc/ipsec.conf's are > > exact mirrors, and the two racoon.conf's are mirrors (with configuration > > names changed to match directions). It /feels/ like the remote (10.0.2.1) > > isn't finding the 'remote 10.0.1.1' configuration section that exists in > > there. I yanked the 'remote anonymous' and 'sainfo anonymous' > > configurations to help narrow this down. > > > > Does anyone have any pointers? Please reply personally, as I'm not > > subscribed. > > > Hmm, on my machines with IPSec tunnels the /etc/ipsec.conf's are > NOT the exact mirrors; they are mirrors except for the in/out > keywords. Yes, sorry, mine are the same way. Two tunnels, two subnets. Each has the appropriate 'out' rule and the appropriate 'in' rule. - Damian From owner-freebsd-net@FreeBSD.ORG Tue Apr 15 22:51:44 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A949137B401 for ; Tue, 15 Apr 2003 22:51:44 -0700 (PDT) Received: from mx1.dev.itouchnet.net (itouchlabs.com [196.15.188.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7A8E43F93 for ; Tue, 15 Apr 2003 22:51:42 -0700 (PDT) (envelope-from bvi@itouchlabs.com) Received: from nobody by mx1.dev.itouchnet.net with scanned_ok (Exim 3.35 #1) id 195fsI-000Crs-00 for net@freebsd.org; Wed, 16 Apr 2003 07:54:26 +0200 X-TLS: TLSv1:RC4-MD5:128 itouchlabs.com -> mx1.dev.itouchnet.net Received: from itouchlabs.com ([196.15.188.2] helo=Beastie) by mx1.dev.itouchnet.net with esmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 195fsH-000Cra-00; Wed, 16 Apr 2003 07:54:25 +0200 Message-ID: <00d001c303dc$191c2830$0b01a8c0@Beastie> From: "Barry Irwin" To: "Damian Gerow" References: <20030415215844.GY648@sentex.net><20030415220310.GB57610@sunbay.com> <20030415223713.GB648@sentex.net> Date: Wed, 16 Apr 2003 07:50:32 +0200 Organization: iTouch Labs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Checked: This message has been scanned for any virusses and unauthorized attachments. X-iScan-ID: 49462-1050472466-02493@unconfigured version $Name: REL_2_0_4 $ cc: net@freebsd.org Subject: Re: IPSec tunnel setup problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 05:51:45 -0000 Hi Can I suggest you try using TCPdump to see whats going on as well. Other things to check: - Phase 1 settings are the same - dh_group etc. - phase 2 settings are the same ( sainfo stuff) pfs, times etc - the psk files are chmod 600 ( been cought by this one before) - The psk files contain either both hosts with the appropriate key, or just the remote host - try upping the debug level on racoon and see if it moans. In my experiance, have almost no trouble getting bsd-bsd IPSEC links talking, biggest pain has been to checkpoint boxes -- Barry Irwin bvi@itouchlabs.com Tel: +27214875178 Systems Administrator: Networks And Security iTouch Technology iTouch TAS http://www.itouchlabs.com Mobile: +27824457210 ----- Original Message ----- From: "Damian Gerow" To: "Ruslan Ermilov" Cc: Sent: Wednesday, April 16, 2003 12:37 AM Subject: Re: IPSec tunnel setup problems > Thus spake Ruslan Ermilov (ru@freebsd.org) [15/04/03 18:04]: > > > The two psk.txt's are exactly the same, the two /etc/ipsec.conf's are > > > exact mirrors, and the two racoon.conf's are mirrors (with configuration > > > names changed to match directions). It /feels/ like the remote (10.0.2.1) > > > isn't finding the 'remote 10.0.1.1' configuration section that exists in > > > there. I yanked the 'remote anonymous' and 'sainfo anonymous' > > > configurations to help narrow this down. > > > > > > Does anyone have any pointers? Please reply personally, as I'm not > > > subscribed. > > > > > Hmm, on my machines with IPSec tunnels the /etc/ipsec.conf's are > > NOT the exact mirrors; they are mirrors except for the in/out > > keywords. > > Yes, sorry, mine are the same way. Two tunnels, two subnets. Each has the > appropriate 'out' rule and the appropriate 'in' rule. > > - Damian > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 06:08:18 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B748A37B404 for ; Wed, 16 Apr 2003 06:08:18 -0700 (PDT) Received: from mail.procreditbank.com (mail.procreditbank.com [212.95.179.198]) by mx1.FreeBSD.org (Postfix) with SMTP id CF40943FB1 for ; Wed, 16 Apr 2003 06:08:16 -0700 (PDT) (envelope-from i.tanusheff@procreditbank.com) Received: (qmail 1412 invoked from network); 16 Apr 2003 13:08:16 -0000 Received: from unknown (HELO itaush) (172.16.248.250) by proxy.procreditbank.bg with SMTP; 16 Apr 2003 13:08:16 -0000 From: "Ivailo Tanusheff" To: "FreeBSD Net" , "FreeBSD Questions" Date: Wed, 16 Apr 2003 16:08:16 +0300 Organization: ProCredit Bank Message-ID: <0a3d01c30419$3e341500$faf810ac@sof.procreditbank.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: Ezmlm need URGENT help X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: I.Tanusheff@procreditbank.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 13:08:19 -0000 Hi, I have several mailing lists. For the purpose of our organization I'll need to make a master mailing list, which will be moderated. I'd like to make the original mailing lists subscribers of the new mailing list, so any approved by moderators e-mail should be forwarded to the other mailing list. I'm not sure why, but the forwarded mails are ignored and not managed by the original lists. May you help me solve this problem? Thank you in advantage, Ivailo Tanusheff From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 06:19:43 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18A9D37B401; Wed, 16 Apr 2003 06:19:43 -0700 (PDT) Received: from mail.cordis.lu (mail.cordis.lu [212.190.217.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC74543FD7; Wed, 16 Apr 2003 06:19:41 -0700 (PDT) (envelope-from a.carter@cordis.lu) Received: from mailsvr.intrasoft.lu (mail.intrasoft.lu [212.190.217.251]) by mail.cordis.lu (8.12.8/8.12.8) with ESMTP id h3GDQZ1d030465; Wed, 16 Apr 2003 15:26:35 +0200 Received: by mail.intrasoft.lu with Internet Mail Service (5.5.2656.59) id <24R4J2SQ>; Wed, 16 Apr 2003 15:16:41 +0200 Received: from intra241.intrasoft.lu (212.190.217.170 [212.190.217.170]) by mailsvr.intrasoft.lu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 24R4J2SP; Wed, 16 Apr 2003 15:16:37 +0200 From: CARTER Anthony To: I.Tanusheff@procreditbank.com, FreeBSD Net , FreeBSD Questions Organization: Intrasoft Date: Wed, 16 Apr 2003 15:20:02 +0200 User-Agent: KMail/1.5.1 References: <0a3d01c30419$3e341500$faf810ac@sof.procreditbank.bg> In-Reply-To: <0a3d01c30419$3e341500$faf810ac@sof.procreditbank.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304161520.02510.a.carter@intrasoft.lu> X-Spam-Status: No, hits=-131.9 required=4.2 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_KMAIL,USER_IN_WHITELIST version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Subject: Re: Ezmlm need URGENT help X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 13:19:43 -0000 Which mailing lists servers are you using? Do I understand this right? ... define old_list, new_list if old_list.member.moderated=TRUE old_list.sendmailto(new_list,old_list.member.email) new_list.member.new(email) but the problem is: a) forwarded mails are ignored (by newlist?) b) not managed by the original list (what exactly does the original list have to manage?) Anthony On Wednesday 16 April 2003 15:08, Ivailo Tanusheff wrote: > Hi, > > I have several mailing lists. For the purpose of our organization I'll > need to make a master mailing list, which will be moderated. I'd like to > make the original mailing lists subscribers of the new mailing list, so > any approved by moderators e-mail should be forwarded to the other > mailing list. I'm not sure why, but the forwarded mails are ignored and > not managed by the original lists. > May you help me solve this problem? > > Thank you in advantage, > Ivailo Tanusheff > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 06:25:37 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDDAB37B401 for ; Wed, 16 Apr 2003 06:25:37 -0700 (PDT) Received: from mail.procreditbank.com (mail.procreditbank.com [212.95.179.198]) by mx1.FreeBSD.org (Postfix) with SMTP id 488ED43F85 for ; Wed, 16 Apr 2003 06:25:36 -0700 (PDT) (envelope-from i.tanusheff@procreditbank.com) Received: (qmail 3788 invoked from network); 16 Apr 2003 13:25:35 -0000 Received: from unknown (HELO itaush) (172.16.248.250) by proxy.procreditbank.bg with SMTP; 16 Apr 2003 13:25:35 -0000 From: "Ivailo Tanusheff" To: "FreeBSD Net" , "FreeBSD Questions" Date: Wed, 16 Apr 2003 16:25:35 +0300 Organization: ProCredit Bank Message-ID: <0a9901c3041b$a9913600$faf810ac@sof.procreditbank.bg> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0A9A_01C30434.CEDE6E00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: RE: Ezmlm need URGENT help X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: I.Tanusheff@procreditbank.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 13:25:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0A9A_01C30434.CEDE6E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have: List1, List2, List3 - not moderated I create a moderated list ListNew and I want mails send to ListNew after approvement by a moderator to be forward to List1, List2 and List3. But I don't know why, List1, List2 and List3 ignore/reject the mail. Ivailo Tanusheff -----Original Message----- From: CARTER Anthony [mailto:a.carter@cordis.lu] Sent: Wednesday, April 16, 2003 4:20 PM To: I.Tanusheff@procreditbank.com; FreeBSD Net; FreeBSD Questions Subject: Re: Ezmlm need URGENT help Which mailing lists servers are you using? Do I understand this right? ... define old_list, new_list if old_list.member.moderated=TRUE old_list.sendmailto(new_list,old_list.member.email) new_list.member.new(email) but the problem is: a) forwarded mails are ignored (by newlist?) b) not managed by the original list (what exactly does the original list have to manage?) Anthony On Wednesday 16 April 2003 15:08, Ivailo Tanusheff wrote: > Hi, > > I have several mailing lists. For the purpose of our organization I'll > need to make a master mailing list, which will be moderated. I'd like > to make the original mailing lists subscribers of the new mailing > list, so any approved by moderators e-mail should be forwarded to the > other mailing list. I'm not sure why, but the forwarded mails are > ignored and not managed by the original lists. May you help me solve > this problem? > > Thank you in advantage, > Ivailo Tanusheff > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" ------=_NextPart_000_0A9A_01C30434.CEDE6E00-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 10:56:01 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EDB537B401; Wed, 16 Apr 2003 10:56:01 -0700 (PDT) Received: from vineyard.net (k1.vineyard.net [204.17.195.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DD8043FAF; Wed, 16 Apr 2003 10:56:00 -0700 (PDT) (envelope-from ericx@vineyard.net) Received: from alice (gw.educompmv.com [204.17.195.36]) by vineyard.net (Postfix) with SMTP id 0CD9F91646; Wed, 16 Apr 2003 13:55:59 -0400 (EDT) Message-ID: <013b01c30441$f19d2960$8c00000a@alice> From: "Eric W. Bates" To: "Kris Kennaway" References: <20030413220816.GA52457@rot13.obsecurity.org> Date: Wed, 16 Apr 2003 13:59:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 cc: current@FreeBSD.org cc: net@FreeBSD.org Subject: Re: Deadlocks running rsync on SMP machine X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 17:56:01 -0000 ----- Original Message ----- From: "Kris Kennaway" To: ; ; Sent: Sunday, April 13, 2003 6:08 PM Subject: Deadlocks running rsync on SMP machine I may be wrong; but I don't believe this problem is new. We have been living with it for some few years now thru several versions of the rsync port and FreeBSD itself. The problem persists with both SMP and single chip machines.. Our work around is simply to segment the transfer into separate rsync processes which we run sequentially. We have never tried to determine what the magic number of files is that causes it to freeze up. e.g.: Syncing /usr/local usually fails, but doing /usr/local/[whatever] hasn't been a problem. --ericx From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 11:52:53 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0474837B401; Wed, 16 Apr 2003 11:52:53 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-63-207-60-150.dsl.lsan03.pacbell.net [63.207.60.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F03643FB1; Wed, 16 Apr 2003 11:52:49 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 301FE66CFA; Wed, 16 Apr 2003 11:52:49 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 1022C1175; Wed, 16 Apr 2003 11:52:49 -0700 (PDT) Date: Wed, 16 Apr 2003 11:52:49 -0700 From: Kris Kennaway To: "Eric W. Bates" Message-ID: <20030416185248.GD68859@rot13.obsecurity.org> References: <20030413220816.GA52457@rot13.obsecurity.org> <013b01c30441$f19d2960$8c00000a@alice> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0/kgSOzhNoDC5T3a" Content-Disposition: inline In-Reply-To: <013b01c30441$f19d2960$8c00000a@alice> User-Agent: Mutt/1.4i cc: net@FreeBSD.org cc: current@FreeBSD.org cc: Kris Kennaway Subject: Re: Deadlocks running rsync on SMP machine X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 18:52:53 -0000 --0/kgSOzhNoDC5T3a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 16, 2003 at 01:59:36PM -0400, Eric W. Bates wrote: >=20 > ----- Original Message ----- > From: "Kris Kennaway" > To: ; ; > Sent: Sunday, April 13, 2003 6:08 PM > Subject: Deadlocks running rsync on SMP machine >=20 > I may be wrong; but I don't believe this problem is new. We have been > living with it for some few years now thru several versions of the rsync > port and FreeBSD itself. The problem persists with both SMP and single ch= ip > machines.. When you say "it", are you talking about rsync freezing, or the entire machine? I'm talking about the latter, but apparently rsync itself has problems that other people see. Kris --0/kgSOzhNoDC5T3a Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+naaAWry0BWjoQKURArCoAJ9/xtEet7vRBbQaSEI5hhMfY2Vb9ACguCJ5 medTtbbLdSedhF7jYsVJa+k= =ypB1 -----END PGP SIGNATURE----- --0/kgSOzhNoDC5T3a-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 12:05:24 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E8B137B401 for ; Wed, 16 Apr 2003 12:05:24 -0700 (PDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14F6A43F93 for ; Wed, 16 Apr 2003 12:05:23 -0700 (PDT) (envelope-from damian@sentex.net) Received: from pegmatite.sentex.ca (pegmatite.sentex.ca [192.168.42.92]) by lava.sentex.ca (8.12.9/8.12.8) with ESMTP id h3GJ5MME085381; Wed, 16 Apr 2003 15:05:22 -0400 (EDT) (envelope-from damian@sentex.net) Received: by pegmatite.sentex.ca (Postfix, from userid 1001) id 7B264170EC; Wed, 16 Apr 2003 15:05:20 -0400 (EDT) Date: Wed, 16 Apr 2003 15:05:20 -0400 From: Damian Gerow To: Barry Irwin Message-ID: <20030416190520.GJ648@sentex.net> References: <20030415223713.GB648@sentex.net> <00d001c303dc$191c2830$0b01a8c0@Beastie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00d001c303dc$191c2830$0b01a8c0@Beastie> X-Operating-System: FreeBSD 5.0-CURRENT on a i386 X-GPG-Key: https://ssl3.sentex.ca/~damian/damian.asc X-GPG-Key-Id: 0xB841F142 X-GPG-Fingerprint: C7C1 E1D1 EC06 7C86 AF7C 57E6 173D 9CF6 B841 F142 User-Agent: Mutt/1.5.3i X-Virus-Scanned: By Sentex Communications (lava/20020517) cc: net@freebsd.org Subject: [LONG] Re: IPSec tunnel setup problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 19:05:24 -0000 Thus spake Barry Irwin (bvi@itouchlabs.com) [16/04/03 01:52]: > Can I suggest you try using TCPdump to see whats going on as well. I've done it. I see continual re-tries for Phase I, nothing for Phase II. Here's what I see: tcpdump: 14:31:33.613674 pyroxene.sentex.ca.isakmp > asylum.afflictions.org.isakmp: isakmp: phase 1 I agg: [|sa] 14:31:53.428132 pyroxene.sentex.ca.isakmp > asylum.afflictions.org.isakmp: isakmp: phase 1 I agg: [|sa] And so on. initiating: 2003-04-16 14:43:09: DEBUG: isakmp_agg.c:162:agg_i1sen): authmethod is pre-shared key 2003-04-16 14:43:09: DEBUG: isakmp.c:2113:set_isakmp_payloa): add payload of len 52, next type 4 2003-04-16 14:43:09: DEBUG: isakmp.c:2113:set_isakmp_payloa): add payload of len 192, next type 10 2003-04-16 14:43:09: DEBUG: isakmp.c:2113:set_isakmp_payloa): add payload of len 16, next type 5 2003-04-16 14:43:09: DEBUG: isakmp.c:2113:set_isakmp_payloa): add payload of len 8, next type 0 2003-04-16 14:43:09: DEBUG: isakmp.c:2248:isakmp_printpacke): begin. 43:09.033625 64.7.134.90:500 -> 199.212.134.18:500: isakmp 1.0 msgid 00000000: phase 1 I agg: sa: doi=ipsec situation=identity p: #1 protoid=isakmp transform=1 t: #1 id=iketype=lifetype value=sectype=lifeduration value=0e10type=enc value=blowfishtype=keylen value=0080type=auth value=presharedtype=hash value=sha1type=group desc value=0005)))) ke: key len=192) nonce: n len=16) id: idtype=IPv4 protoid=udp port=500 len=4 64.7.134.90) 2003-04-16 14:43:09: DEBUG: sockmisc.c:421:sendfromt): sockname 64.7.134.90[500] 2003-04-16 14:43:09: DEBUG: sockmisc.c:423:sendfromt): send packet from 64.7.134.90[500] 2003-04-16 14:43:09: DEBUG: sockmisc.c:425:sendfromt): send packet to 199.212.134.18[500] 2003-04-16 14:43:09: DEBUG: sockmisc.c:570:sendfromt): 1 times of 312 bytes message will be sent to 64.7.134.90[500] 2003-04-16 14:43:09: DEBUG: plog.c:193:plogdum): 915b0922 44d7fb35 00000000 00000000 01100400 00000000 00000138 04000038 00000001 00000001 0000002c 01010001 00000024 01010000 800b0001 800c0e10 80010003 800e0080 80030001 80020002 80040005 0a0000c4 8c687103 3ceab145 1f1fda2e 8210ae56 12ed3492 d3bf3a20 931c12d2 96631473 71ccebb7 b0d4e3a8 674dfba6 ee7d6085 9f83a55a 85c9dd16 575485ec 06e29bd9 4c347b98 f33940c7 e5ff7a41 10a83a78 ed576db8 bc325492 301eacdc ed00ccba 2a3e1165 ed772d57 760e8201 3467c440 28352967 13e030b9 a3404356 6339f699 955c074c 2239ce9b ef519853 62edb648 4be54c09 f54d7d49 65bf7592 806a8554 47362099 461fbc39 9efbfedc bdb94b53 8fb1d9a9 525acc05 0aea8a6c e53408b9 05000014 953e119c 29e492ca fee18307 e7c6ab9c 0000000c 011101f4 4007865a 2003-04-16 14:43:09: DEBUG: isakmp.c:1449:isakmp_ph1resen): resend phase1 packet 915b092244d7fb35:0000000000000000 receiving: 2003-04-16 14:40:07: DEBUG: isakmp.c:221:isakmp_handler(): === 2003-04-16 14:40:07: DEBUG: isakmp.c:222:isakmp_handler(): 312 bytes message received from 64.7.134.90[41889] 2003-04-16 14:40:07: DEBUG: plog.c:193:plogdump(): 915b0922 44d7fb35 00000000 00000000 01100400 00000000 00000138 04000038 00000001 00000001 0000002c 01010001 00000024 01010000 800b0001 800c0e10 80010003 800e0080 80030001 80020002 80040005 0a0000c4 8c687103 3ceab145 1f1fda2e 8210ae56 12ed3492 d3bf3a20 931c12d2 96631473 71ccebb7 b0d4e3a8 674dfba6 ee7d6085 9f83a55a 85c9dd16 575485ec 06e29bd9 4c347b98 f33940c7 e5ff7a41 10a83a78 ed576db8 bc325492 301eacdc ed00ccba 2a3e1165 ed772d57 760e8201 3467c440 28352967 13e030b9 a3404356 6339f699 955c074c 2239ce9b ef519853 62edb648 4be54c09 f54d7d49 65bf7592 806a8554 47362099 461fbc39 9efbfedc bdb94b53 8fb1d9a9 525acc05 0aea8a6c e53408b9 05000014 953e119c 29e492ca fee18307 e7c6ab9c 0000000c 011101f4 4007865a 2003-04-16 14:40:07: DEBUG: isakmp.c:2248:isakmp_printpacket(): begin. 40:07.915101 64.7.134.90:41889 -> 199.212.134.18:500: isakmp 1.0 msgid 00000000: phase 1 I agg: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=1 (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration value=0e10)(type=enc value=blowfish)(type=keylen value=0080)(type=auth value=preshared)(type=hash value=sha1)(type=group desc value=0005)))) (ke: key len=192) (nonce: n len=16) (id: idtype=IPv4 protoid=udp port=500 len=4 64.7.134.90) 2003-04-16 14:40:07: DEBUG: remoteconf.c:134:getrmconf(): no remote configuration found. 2003-04-16 14:40:07: ERROR: isakmp.c:851:isakmp_ph1begin_r(): couldn't find configuration. So I'm seeing one host send something off to the other, who is completely ignoring the packet. I /did/ notice that the timestamps are a bit off, but I would't think this matters...? I tried setting the timestamps to match, same problem as above. Interestingly, if I go the /other/ way, I see the following message: initiating (was: receiving): 2003-04-16 14:47:41: DEBUG: isakmp.c:221:isakmp_handle): === 2003-04-16 14:47:41: DEBUG: isakmp.c:222:isakmp_handle): 312 bytes message received from 199.212.134.18[500] 2003-04-16 14:47:41: DEBUG: plog.c:193:plogdum): f9221b58 980142e7 00000000 00000000 01100400 00000000 00000138 04000038 00000001 00000001 0000002c 01010001 00000024 01010000 800b0001 800c0e10 80010003 800e0080 80030001 80020002 80040005 0a0000c4 0130413e 2a9c630e e71311f8 582c580c 5165167c 7736edac 68843d01 f818060f c5a41c15 4cbbbefb eb628f36 c02d6033 a086e794 b4407c0e 93ebe3a4 016cc872 5b9b5c57 6107b506 273c309a 32f6b2d2 1e4165d5 7a076f4e e8710f97 ac35d559 9015dbcb 04e34479 9beb3f58 cffae12a 206e6e0c 01e92971 fe183f42 452dd46c 0b1dfce0 c5467929 e2fb4464 4a9869de b8a4cfda ca97b6d1 8d64c22d 517fe531 11b44c0b 113ca02e 04943290 05e63b20 3b4233ae 2c41c73e 9e9a7bcf 8e1fc13b 05000014 d95c7669 982aeb86 791ae2fc 38eaaa13 0000000c 011101f4 c7d48612 2003-04-16 14:47:41: DEBUG: isakmp.c:2248:isakmp_printpacke): begin. 47:41.847966 199.212.134.18:500 -> 64.7.134.90:500: isakmp 1.0 msgid 00000000: phase 1 I agg: sa: doi=ipsec situation=identity p: #1 protoid=isakmp transform=1 t: #1 id=iketype=lifetype value=sectype=lifeduration value=0e10type=enc value=blowfishtype=keylen value=0080type=auth value=presharedtype=hash value=sha1type=group desc value=0005)))) ke: key len=192) nonce: n len=16) id: idtype=IPv4 protoid=udp port=500 len=4 199.212.134.18) 2003-04-16 14:47:41: DEBUG: remoteconf.c:118:getrmcon): configuration found for 199.212.134.18[500]. 2003-04-16 14:47:41: DEBUG: isakmp.c:889:isakmp_ph1begin_): === 2003-04-16 14:47:41: INFO: isakmp.c:894:isakmp_ph1begin_): respond new phase 1 negotiation: 64.7.134.90[500]<=>199.212.134.18[500] 2003-04-16 14:47:41: INFO: isakmp.c:899:isakmp_ph1begin_): begin Aggressive mode. 2003-04-16 14:47:41: DEBUG: isakmp.c:1112:isakmp_parsewo): begin. 2003-04-16 14:47:41: DEBUG: isakmp.c:1139:isakmp_parsewo): seen nptype=sa) 2003-04-16 14:47:41: DEBUG: isakmp.c:1139:isakmp_parsewo): seen nptype=ke) 2003-04-16 14:47:41: DEBUG: isakmp.c:1139:isakmp_parsewo): seen nptype=1nonce) 2003-04-16 14:47:41: DEBUG: isakmp.c:1139:isakmp_parsewo): seen nptype=id) 2003-04-16 14:47:41: DEBUG: isakmp.c:1178:isakmp_parsewo): succeed. 2003-04-16 14:47:41: DEBUG: isakmp_agg.c:649:agg_r1rec): received payload of type ke 2003-04-16 14:47:41: DEBUG: isakmp_agg.c:649:agg_r1rec): received payload of type nonce 2003-04-16 14:47:41: DEBUG: isakmp_agg.c:649:agg_r1rec): received payload of type id 2003-04-16 14:47:41: WARNING: ipsec_doi.c:3059:ipsecdoi_checkid): ID value mismatched. 2003-04-16 14:47:41: ERROR: isakmp_agg.c:697:agg_r1rec): invalid ID payload. 2003-04-16 14:47:41: ERROR: isakmp.c:913:isakmp_ph1begin_): failed to process packet. receiving (was: initiating): 2003-04-16 14:44:40: DEBUG: isakmp_agg.c:162:agg_i1sen): authmethod is pre-shared key 2003-04-16 14:44:40: DEBUG: isakmp.c:2113:set_isakmp_payloa): add payload of len 52, next type 4 2003-04-16 14:44:40: DEBUG: isakmp.c:2113:set_isakmp_payloa): add payload of len 192, next type 10 2003-04-16 14:44:40: DEBUG: isakmp.c:2113:set_isakmp_payloa): add payload of len 16, next type 5 2003-04-16 14:44:40: DEBUG: isakmp.c:2113:set_isakmp_payloa): add payload of len 8, next type 0 2003-04-16 14:44:40: DEBUG: isakmp.c:2248:isakmp_printpacke): begin. 44:40.221157 199.212.134.18:500 -> 64.7.134.90:500: isakmp 1.0 msgid 00000000: phase 1 I agg: sa: doi=ipsec situation=identity p: #1 protoid=isakmp transform=1 t: #1 id=iketype=lifetype value=sectype=lifeduration value=0e10type=enc value=blowfishtype=keylen value=0080type=auth value=presharedtype=hash value=sha1type=group desc value=0005)))) ke: key len=192) nonce: n len=16) id: idtype=IPv4 protoid=udp port=500 len=4 199.212.134.18) 2003-04-16 14:44:40: DEBUG: sockmisc.c:421:sendfromt): sockname 199.212.134.18[500] 2003-04-16 14:44:40: DEBUG: sockmisc.c:423:sendfromt): send packet from 199.212.134.18[500] 2003-04-16 14:44:40: DEBUG: sockmisc.c:425:sendfromt): send packet to 64.7.134.90[500] 2003-04-16 14:44:40: DEBUG: sockmisc.c:570:sendfromt): 1 times of 312 bytes message will be sent to 199.212.134.18[500] 2003-04-16 14:44:40: DEBUG: plog.c:193:plogdum): f9221b58 980142e7 00000000 00000000 01100400 00000000 00000138 04000038 00000001 00000001 0000002c 01010001 00000024 01010000 800b0001 800c0e10 80010003 800e0080 80030001 80020002 80040005 0a0000c4 0130413e 2a9c630e e71311f8 582c580c 5165167c 7736edac 68843d01 f818060f c5a41c15 4cbbbefb eb628f36 c02d6033 a086e794 b4407c0e 93ebe3a4 016cc872 5b9b5c57 6107b506 273c309a 32f6b2d2 1e4165d5 7a076f4e e8710f97 ac35d559 9015dbcb 04e34479 9beb3f58 cffae12a 206e6e0c 01e92971 fe183f42 452dd46c 0b1dfce0 c5467929 e2fb4464 4a9869de b8a4cfda ca97b6d1 8d64c22d 517fe531 11b44c0b 113ca02e 04943290 05e63b20 3b4233ae 2c41c73e 9e9a7bcf 8e1fc13b 05000014 d95c7669 982aeb86 791ae2fc 38eaaa13 0000000c 011101f4 c7d48612 2003-04-16 14:44:40: DEBUG: isakmp.c:1449:isakmp_ph1resen): resend phase1 packet f9221b58980142e7:0000000000000000 So instead of a 'configuration not found' message, I'm seeing 'invalid ID payload'. > Other things to check: > - Phase 1 settings are the same - dh_group etc. Following the first format above: initiating: remote 199.212.134.18 { #exchange_mode main,aggressive; exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; my_identifier address 64.7.134.90; peers_identifier address 199.212.134.18; verify_identifier on; nonce_size 16; lifetime time 60 min; # sec,min,hour initial_contact on; support_mip6 on; proposal_check obey; # obey, strict or claim proposal { encryption_algorithm blowfish; hash_algorithm sha1; authentication_method pre_shared_key; dh_group modp1536; } } receiving: remote 64.7.134.90 { #exchange_mode main,aggressive; exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; my_identifier address 199.212.134.18; peers_identifier address 64.7.134.90; verify_identifier on; nonce_size 16; lifetime time 60 min; # sec,min,hour initial_contact on; support_mip6 on; proposal_check obey; # obey, strict or claim proposal { encryption_algorithm blowfish; hash_algorithm sha1; authentication_method pre_shared_key; dh_group modp1536; } } The two look fine to me. But then again, I'm the one having troubles. :) > - phase 2 settings are the same ( sainfo stuff) pfs, times etc I have four sections, each going each way. Two for 64.7.134.90<->199.212.134.18, and two for 172.16.0.0/24<->192.168.42.0/24. So replace the two addresses below to handle the four possibilities. initiating: sainfo address 64.7.134.90 any address 199.212.134.18 any { pfs_group modp1536; lifetime time 60 min; encryption_algorithm blowfish; authentication_algorithm hmac_sha1; compression_algorithm deflate; } receiving: sainfo address 199.212.134.18 any address 64.7.134.90 any { pfs_group modp1536; lifetime time 60 min; encryption_algorithm blowfish; authentication_algorithm hmac_sha1; compression_algorithm deflate; } Again, these look pretty okay to me. But again, that's me. > - the psk files are chmod 600 ( been cought by this one before) Checked and double-checked. > - The psk files contain either both hosts with the appropriate key, or just > the remote host Just the remote host: initiating: 199.212.134.18 hellojellohellojellohellojello receiving: 64.7.134.90 hellojellohellojellohellojello Yes, that's what I'm trying with right now. I have another shared secret for actual production use. > - try upping the debug level on racoon and see if it moans. I'm already running at DEBUG. I can try DEBUG2... And just for thoroughness, here's my /etc/ipsec.conf: initiating: flush; spdflush; spdadd 192.168.42.0/24 172.16.0.0/24 any -P in ipsec esp/tunnel/199.212.134.18-64.7.134.90/require; spdadd 172.16.0.0/24 192.168.42.0/24 any -P out ipsec esp/tunnel/64.7.134.90-199.212.134.18/require ; receiving: flush; spdflush; spdadd 192.168.42.0/24 172.16.0.0/24 any -P out ipsec esp/tunnel/199.212.134.18-64.7.134.90/require; spdadd 172.16.0.0/24 192.168.42.0/24 any -P in ipsec esp/tunnel/64.7.134.90-199.212.134.18/require; Something looks funny about these, but I can't tell what... > In my experiance, have almost no trouble getting bsd-bsd IPSEC links > talking, biggest pain has been to checkpoint boxes Yeah, I'm ~100% sure this is a configuration error, I just can't figure out /where/. I've worked with IPSec before (FreeS/WAN), and within the same implementation, the error's always been user error. Side note, I just tried changing the exchange_mode on both of them to main,aggressive instead of aggressive,main. Here's the new tcpdump I see: 15:03:36.591876 pyroxene.sentex.ca.isakmp > asylum.afflictions.org.isakmp: isakmp: phase 1 I ident: [|sa] 15:03:37.031774 asylum.afflictions.org.isakmp > pyroxene.sentex.ca.isakmp: isakmp: phase 1 R ident: [|sa] 15:03:37.181992 pyroxene.sentex.ca.isakmp > asylum.afflictions.org.isakmp: isakmp: phase 1 I ident: [|ke] 15:03:38.545255 asylum.afflictions.org.isakmp > pyroxene.sentex.ca.isakmp: isakmp: phase 1 R ident: [|ke] 15:03:38.711593 pyroxene.sentex.ca.isakmp > asylum.afflictions.org.isakmp: isakmp: phase 1 I ident[E]: [encrypted id] 15:03:48.727758 asylum.afflictions.org.isakmp > pyroxene.sentex.ca.isakmp: isakmp: phase 1 R ident: [|ke] 15:03:48.731077 pyroxene.sentex.ca.isakmp > asylum.afflictions.org.isakmp: isakmp: phase 1 I ident[E]: [encrypted id] That looks a /little/ more promising, but I wouldn't have thought it would have mattered that much...? Both machines are running 4.8-RC, the initiator as of Apr. 2 and the receiver as of Mar 15. From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 18:37:11 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DE4C37B405; Wed, 16 Apr 2003 18:37:11 -0700 (PDT) Received: from vineyard.net (k1.vineyard.net [204.17.195.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 978FD43FBD; Wed, 16 Apr 2003 18:37:10 -0700 (PDT) (envelope-from ericx@vineyard.net) Received: from alice (alice.ericx.net [204.128.227.62]) by vineyard.net (Postfix) with SMTP id 11A17917A6; Wed, 16 Apr 2003 21:37:10 -0400 (EDT) Message-ID: <025b01c30482$5f691e50$8c00000a@alice> From: "Eric W. Bates" To: "Kris Kennaway" References: <20030413220816.GA52457@rot13.obsecurity.org> <013b01c30441$f19d2960$8c00000a@alice> <20030416185248.GD68859@rot13.obsecurity.org> Date: Wed, 16 Apr 2003 21:40:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 cc: net@FreeBSD.org cc: current@FreeBSD.org cc: Kris Kennaway Subject: Re: Deadlocks running rsync on SMP machine X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 01:37:11 -0000 Sorry, By 'it', I mean the rsync process on the receiving machine. The process on the sending machine eventually times out; but the process on the receiving machine will sit there forever. Once we learned that the problem could be avoided by keeping the file list small; I decided I would wait for smarter folk to figure it out. ----- Original Message ----- From: "Kris Kennaway" To: "Eric W. Bates" Cc: "Kris Kennaway" ; ; Sent: Wednesday, April 16, 2003 2:52 PM Subject: Re: Deadlocks running rsync on SMP machine On Wed, Apr 16, 2003 at 01:59:36PM -0400, Eric W. Bates wrote: >=20 > ----- Original Message ----- > From: "Kris Kennaway" > To: ; ; > Sent: Sunday, April 13, 2003 6:08 PM > Subject: Deadlocks running rsync on SMP machine >=20 > I may be wrong; but I don't believe this problem is new. We have been > living with it for some few years now thru several versions of the rsync > port and FreeBSD itself. The problem persists with both SMP and single ch= ip > machines.. When you say "it", are you talking about rsync freezing, or the entire machine? I'm talking about the latter, but apparently rsync itself has problems that other people see. Kris From owner-freebsd-net@FreeBSD.ORG Wed Apr 16 19:13:04 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F38CA37B401; Wed, 16 Apr 2003 19:13:03 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-63-207-60-150.dsl.lsan03.pacbell.net [63.207.60.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id E89C043FD7; Wed, 16 Apr 2003 19:13:02 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 6492C66D74; Wed, 16 Apr 2003 19:13:01 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 4DE421164; Wed, 16 Apr 2003 19:13:01 -0700 (PDT) Date: Wed, 16 Apr 2003 19:13:01 -0700 From: Kris Kennaway To: "Eric W. Bates" Message-ID: <20030417021301.GA73049@rot13.obsecurity.org> References: <20030413220816.GA52457@rot13.obsecurity.org> <013b01c30441$f19d2960$8c00000a@alice> <20030416185248.GD68859@rot13.obsecurity.org> <025b01c30482$5f691e50$8c00000a@alice> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: <025b01c30482$5f691e50$8c00000a@alice> User-Agent: Mutt/1.4i cc: net@FreeBSD.org cc: current@FreeBSD.org cc: Kris Kennaway Subject: Re: Deadlocks running rsync on SMP machine X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 02:13:04 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 16, 2003 at 09:40:48PM -0400, Eric W. Bates wrote: > Sorry, >=20 > By 'it', I mean the rsync process on the receiving machine. OK, that's not relevant here then. Kris --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+ng2tWry0BWjoQKURAn2UAJ9/saODtAb1sGWD0mxv/SGqD8z4AACcCAx9 +eszWahq7CaoUzRAEKPZsvo= =sjcX -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 00:20:29 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A582B37B401 for ; Thu, 17 Apr 2003 00:20:29 -0700 (PDT) Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B30B43FBD for ; Thu, 17 Apr 2003 00:20:28 -0700 (PDT) (envelope-from langd@informatik.tu-muenchen.de) Received: from mailrelay1.informatik.tu-muenchen.de (mailrelay1.informatik.tu-muenchen.de [131.159.254.5])9BA3C622E for ; Thu, 17 Apr 2003 09:20:27 +0200 (MEST) Received: from atrbg11.informatik.tu-muenchen.de (atrbg11.informatik.tu-muenchen.de [131.159.42.129])8E0B07943 for ; Thu, 17 Apr 2003 09:20:27 +0200 (MEST) Received: by atrbg11.informatik.tu-muenchen.de (Postfix, from userid 20455) id 6437413B5D; Thu, 17 Apr 2003 09:20:27 +0200 (CEST) Date: Thu, 17 Apr 2003 09:20:27 +0200 From: Daniel Lang To: freebsd-net@freebsd.org Message-ID: <20030417072027.GA38782@atrbg11.informatik.tu-muenchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y+ User-Agent: Mutt/1.5.1i Subject: IPfilter changes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 07:20:29 -0000 Hi folks, I've noticed some change of behaviour with IPFilter in my 4.8-RC2 system after the upgrade. It seems that a more recent version of ipfilter was imported then, so maybe something may have changed indeed. I have a pretty tight filter setup, but I make use of keep state rules for outgoing packets. Thus, I have the following rule in my set: @2200 pass out quick proto tcp/udp from any to any keep frags keep state This worked in the past for tcp and also for udp connections, like DNS requests. It still works for TCP, but no longer for DNS. The packets are no longer allowed through. Maybe it was never intended to work for UDP? Or maybe the state timings have changed? Of course I can just open UDP to our name server machine. But I was wondering, if the new behaviour is intended or maybe a bug, or my setup ever just worked by chance. ;) Thanks, Daniel -- IRCnet: Mr-Spock - All your .sigs are belong to us - Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/ From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 02:00:40 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2501D37B401 for ; Thu, 17 Apr 2003 02:00:40 -0700 (PDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C28FF43FB1 for ; Thu, 17 Apr 2003 02:00:38 -0700 (PDT) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h3H90aVI020414; Thu, 17 Apr 2003 11:00:37 +0200 (CEST) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6422FE568; Thu, 17 Apr 2003 10:56:16 +0200 (CEST) Message-ID: <3E9E6D34.5020100@ccrle.nec.de> Date: Thu, 17 Apr 2003 11:00:36 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Lang References: <20030417072027.GA38782@atrbg11.informatik.tu-muenchen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org Subject: Re: IPfilter changes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 09:00:40 -0000 Hi Daniel, Daniel Lang wrote: > Hi folks, > > I've noticed some change of behaviour with IPFilter > in my 4.8-RC2 system after the upgrade. It seems that > a more recent version of ipfilter was imported then, > so maybe something may have changed indeed. What version is used in 4.8-RC2? I'm using 4.8-RELEASE with IPFilter 3.4.31 and it works with UDP and keep state quite fine. > > Maybe it was never intended to work for UDP? Or maybe the state > timings have changed? Yes, it is intended to have UDP and keep state, it is a nice feature of IP Filter! Gruß Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 02:07:55 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CDEC37B401 for ; Thu, 17 Apr 2003 02:07:55 -0700 (PDT) Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A10B43F3F for ; Thu, 17 Apr 2003 02:07:54 -0700 (PDT) (envelope-from langd@informatik.tu-muenchen.de) Received: from mailrelay1.informatik.tu-muenchen.de (mailrelay1.informatik.tu-muenchen.de [131.159.254.5]) by mailout.informatik.tu-muenchen.de (Postfix) with ESMTP id DD3AE6176; Thu, 17 Apr 2003 11:07:53 +0200 (MEST) Received: from atrbg11.informatik.tu-muenchen.de (atrbg11.informatik.tu-muenchen.de [131.159.42.129]) by mailrelay1.informatik.tu-muenchen.de (Postfix) with ESMTP id CFFDB7943; Thu, 17 Apr 2003 11:07:53 +0200 (MEST) Received: by atrbg11.informatik.tu-muenchen.de (Postfix, from userid 20455) id B30B913B5D; Thu, 17 Apr 2003 11:07:53 +0200 (CEST) Date: Thu, 17 Apr 2003 11:07:53 +0200 From: Daniel Lang To: Martin Stiemerling Message-ID: <20030417090753.GI38782@atrbg11.informatik.tu-muenchen.de> References: <20030417072027.GA38782@atrbg11.informatik.tu-muenchen.de> <3E9E6D34.5020100@ccrle.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E9E6D34.5020100@ccrle.nec.de> X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y+ User-Agent: Mutt/1.5.1i cc: freebsd-net@freebsd.org Subject: Re: IPfilter changes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 09:07:55 -0000 Hi Martin, Martin Stiemerling wrote on Thu, Apr 17, 2003 at 11:00:36AM +0200: [..] > What version is used in 4.8-RC2? I'm using 4.8-RELEASE with IPFilter > 3.4.31 and it works with UDP and keep state quite fine. Yes, it's 3.4.31. [..] > Yes, it is intended to have UDP and keep state, it is a nice feature of > IP Filter! Well, then I have to dig deeper. :) Thanks so far, Daniel -- IRCnet: Mr-Spock - signs of absurd developments in the net community: #42: - "Wurstbrot gehoert m.E. zum Fruehstuecks-botnet von Cartoon" - Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/ From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 02:11:37 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A7CB37B401 for ; Thu, 17 Apr 2003 02:11:37 -0700 (PDT) Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68F3B43F75 for ; Thu, 17 Apr 2003 02:11:36 -0700 (PDT) (envelope-from langd@informatik.tu-muenchen.de) Received: from mailrelay1.informatik.tu-muenchen.de (mailrelay1.informatik.tu-muenchen.de [131.159.254.5])BC437626E for ; Thu, 17 Apr 2003 11:11:35 +0200 (MEST) Received: from atrbg11.informatik.tu-muenchen.de (atrbg11.informatik.tu-muenchen.de [131.159.42.129])AFC507943 for ; Thu, 17 Apr 2003 11:11:35 +0200 (MEST) Received: by atrbg11.informatik.tu-muenchen.de (Postfix, from userid 20455) id 98C7513B5D; Thu, 17 Apr 2003 11:11:35 +0200 (CEST) Date: Thu, 17 Apr 2003 11:11:35 +0200 From: Daniel Lang To: freebsd-net@freebsd.org Message-ID: <20030417091135.GJ38782@atrbg11.informatik.tu-muenchen.de> References: <20030417072027.GA38782@atrbg11.informatik.tu-muenchen.de> <3E9E6D34.5020100@ccrle.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E9E6D34.5020100@ccrle.nec.de> X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y+ User-Agent: Mutt/1.5.1i Subject: Re: IPfilter changes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 09:11:37 -0000 Update, I've just noticed, that it doesn't work for tcp connections either, at least for whois. I could confirm this with tcpdump and ipfilter. I see the whois-reply in tcpdump (which attaches in front of the filter), but get it blocked in the ipfilter log. Best regards, Daniel -- IRCnet: Mr-Spock - My name is Pentium of Borg, division is futile, you will be approximated. - Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/ From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 04:01:08 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCF5A37B401 for ; Thu, 17 Apr 2003 04:01:08 -0700 (PDT) Received: from x86unx3.comp.nus.edu.sg (x86unx3.comp.nus.edu.sg [137.132.90.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC63043FBD for ; Thu, 17 Apr 2003 04:01:04 -0700 (PDT) (envelope-from rahulcha@comp.nus.edu.sg) Received: from e500a.comp.nus.edu.sg (e500a.comp.nus.edu.sg [137.132.90.23]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with SMTP id TAA21703 for ; Thu, 17 Apr 2003 19:01:00 +0800 (GMT-8) Received: from sf3.comp.nus.edu.sg(137.132.90.55) by e500a.comp.nus.edu.sg via csmap id 19806; Thu, 17 Apr 2003 11:00:47 +0000 (UTC) Received: from localhost (rahulcha@localhost) by sf3.comp.nus.edu.sg (8.8.5/8.8.5) with ESMTP id TAA27940 for ; Thu, 17 Apr 2003 19:00:59 +0800 (GMT-8) Date: Thu, 17 Apr 2003 19:00:59 +0800 (GMT-8) From: Rahul Chaudhary To: freebsd-net@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Multi Level IPSec implementation for FreeBSD 4.5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 11:01:09 -0000 Hi All, I would like to know if any Multi Level IPSec (ML IPSec) implementation exists for FreeBSD4.5 Any information or pointer in this regard is welcome. TIA. Rahul Chaudhary email- rahulcha@comp.nus.edu.sg From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 10:40:10 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A71D137B404 for ; Thu, 17 Apr 2003 10:40:10 -0700 (PDT) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9168043F93 for ; Thu, 17 Apr 2003 10:40:08 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id LAA22989 for ; Thu, 17 Apr 2003 11:39:58 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030417113242.02aeac20@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Apr 2003 11:39:55 -0600 To: freebsd-net@freebsd.org From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 17:40:11 -0000 I've got an interesting problem that I'm not sure how to solve. Here's the situation. A FreeBSD router is set up to allow a host outside, on the Internet, to tunnel into a LAN via PPTP. The router is running PoPToP and FreeBSD's userland PPP. The internal LAN uses the addresses 192.168/16, and the internal interface of the router is configured with the /16 subnet mask. When the client (which is running Windows) connects, it's given a fixed IP, specified in the ppp.secret file, corresponding to the user who is tunneling in. But the client's routing table has a routing table entry that directs packets for 192.168/24 (NOT /16) to the PPTP connection. I can't find a way to cause userland PPP to tell the Windows client that it should be using a different subnet mask. (There's no way to specify one in the ppp.secret file.) How is this done? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 11:18:59 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80A0E37B407 for ; Thu, 17 Apr 2003 11:18:59 -0700 (PDT) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1699F43F93 for ; Thu, 17 Apr 2003 11:18:58 -0700 (PDT) (envelope-from sten.daniel.sorsdal@wan.no) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Apr 2003 20:18:47 +0200 Message-ID: <0AF1BBDF1218F14E9B4CCE414744E70F07DE91@exchange.wanglobal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Userland PPP/PPTP tunneling problem Thread-Index: AcMFCVr/c5CvxaWSSAqe8ma/GQyhFQAAuz2w From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: "Brett Glass" , Subject: RE: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 18:18:59 -0000 > I've got an interesting problem that I'm not sure how to solve. Here's = > the situation. A FreeBSD router is set up to allow a host outside, on = the=20 > Internet, to tunnel into a LAN via PPTP. The router is running PoPToP = and=20 > FreeBSD's userland PPP. The internal LAN uses the addresses = 192.168/16,=20 > and the internal interface of the router is configured with the /16=20 > subnet mask. > When the client (which is running Windows) connects, it's given a = fixed=20 > IP, specified in the ppp.secret file, corresponding to the user who is = > tunneling in. But the client's routing table has a routing table entry = > that directs packets for 192.168/24 (NOT /16) to the PPTP connection. > I can't find a way to cause userland PPP to tell the Windows client = that=20 > it should be using a different subnet mask. (There's no way to specify = > one in the ppp.secret file.) How is this done? This is a known issue with the Microsoft PPTP client. It adds the = natural netmask and not the specified one. In case of 192.168.x.x/16 that is a=20 255.255.255.0 netmask and with for example 80.80.80.0/24 is 80.0.0.0/8. The only known workarounds AFAIK are requiring the client to default = route Through the tunnel - or - setup a (persistent?) route on the windows = box. Say if client gets 192.168.1.2 when client connects, you need to = manually Enter: route -p add 192.168.0.0 mask 255.255.0.0 192.168.1.2 On the windows client before connecting. Microsoft doesnt seem to be interested in fixing this problem as the = problem persist even on Windows XP and has been known since Windows 98(??).=20 - Sten From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 11:27:40 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E688137B404 for ; Thu, 17 Apr 2003 11:27:40 -0700 (PDT) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE5B643F75 for ; Thu, 17 Apr 2003 11:27:39 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id MAA23532; Thu, 17 Apr 2003 12:27:19 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030417122205.02aed700@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Apr 2003 12:27:08 -0600 To: Sten Daniel Sørsdal , From: Brett Glass In-Reply-To: <0AF1BBDF1218F14E9B4CCE414744E70F07DE91@exchange.wanglobal. net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Subject: RE: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 18:27:41 -0000 At 12:18 PM 4/17/2003, Sten Daniel Sørsdal wrote: >This is a known issue with the Microsoft PPTP client. It adds the natural >netmask and not the specified one. I don't understand. Why is /24 more "natural" than /16? >In case of 192.168.x.x/16 that is a >255.255.255.0 netmask and with for example 80.80.80.0/24 is 80.0.0.0/8. Even more confusion. How does it come up with that? >The only known workarounds AFAIK are requiring the client to default route >Through the tunnel Which causes slowdowns and a huge extra drain on the office's Internet feed >- or - setup a (persistent?) route on the windows box. I suppose we could try a script. >Say if client gets 192.168.1.2 when client connects, you need to manually >Enter: route -p add 192.168.0.0 mask 255.255.0.0 192.168.1.2 >On the windows client before connecting. Is there a way to fire off a script automatically after connecting? >Microsoft doesnt seem to be interested in fixing this problem as the problem >persist even on Windows XP and has been known since Windows 98(??). Figures. --Brett From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 11:29:22 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8306037B401 for ; Thu, 17 Apr 2003 11:29:22 -0700 (PDT) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A53E743F85 for ; Thu, 17 Apr 2003 11:29:21 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id MAA23544; Thu, 17 Apr 2003 12:29:16 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030417122813.02aeaaf0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Apr 2003 12:29:04 -0600 To: Sten Daniel Sørsdal , From: Brett Glass In-Reply-To: <0AF1BBDF1218F14E9B4CCE414744E70F07DE91@exchange.wanglobal. net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: RE: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 18:29:22 -0000 Oh, and one more question. Suppose we change the LAN which the client is tunneling into to a /24. (We can, if we rearrange a few hosts.) Will Windows then do the right thing? --Brett From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 12:26:09 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A72637B401 for ; Thu, 17 Apr 2003 12:26:09 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF8C243F3F for ; Thu, 17 Apr 2003 12:26:08 -0700 (PDT) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id B985D2ED416; Thu, 17 Apr 2003 12:26:08 -0700 (PDT) Date: Thu, 17 Apr 2003 12:26:08 -0700 From: Bill Fumerola To: Brett Glass Message-ID: <20030417192608.GI47855@elvis.mu.org> References: <0AF1BBDF1218F14E9B4CCE414744E70F07DE91@exchange.wanglobal.net> <4.3.2.7.2.20030417122205.02aed700@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4.3.2.7.2.20030417122205.02aed700@localhost> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.8-MUORG-20030411 i386 cc: freebsd-net@freebsd.org Subject: Re: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 19:26:09 -0000 On Thu, Apr 17, 2003 at 12:27:08PM -0600, Brett Glass wrote: > At 12:18 PM 4/17/2003, Sten Daniel S?rsdal wrote: > > >This is a known issue with the Microsoft PPTP client. It adds the natural > >netmask and not the specified one. > > I don't understand. Why is /24 more "natural" than /16? because that address is in class C space, not class B. read rfc791. > >In case of 192.168.x.x/16 that is a > >255.255.255.0 netmask and with for example 80.80.80.0/24 is 80.0.0.0/8. > > Even more confusion. How does it come up with that? rfc791. specifically, because 192.168.x.x has the two highest bits set (which makes it a class C address) and 80.80.80.0's highest bit is set to 0 (which makes it a class A address). you're trying to apply rfc1518 and rfc1519 (cidr routing) and from what Mr. Sørsdal is telling us, msft pptp just doesn't support that. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 12:49:16 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1572137B401 for ; Thu, 17 Apr 2003 12:49:16 -0700 (PDT) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id A766943FCB for ; Thu, 17 Apr 2003 12:49:14 -0700 (PDT) (envelope-from sten.daniel.sorsdal@wan.no) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Apr 2003 21:49:03 +0200 Message-ID: <0AF1BBDF1218F14E9B4CCE414744E70F1F3CEB@exchange.wanglobal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Userland PPP/PPTP tunneling problem Thread-Index: AcMFDwFyQmbFPzDlQWGFRwWYpT9mbgACsZeA From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: "Brett Glass" , Subject: RE: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 19:49:16 -0000 > At 12:18 PM 4/17/2003, Sten Daniel S=F8rsdal wrote: >=20 > >This is a known issue with the Microsoft PPTP client. It=20 > adds the natural > >netmask and not the specified one.=20 >=20 > I don't understand. Why is /24 more "natural" than /16? It's how the entire IP block is arranged I assume. I don't know=20 exactly what benefits there are from such a arrangement. >=20 > >In case of 192.168.x.x/16 that is a=20 > >255.255.255.0 netmask and with for example 80.80.80.0/24 is=20 > 80.0.0.0/8. >=20 > Even more confusion. How does it come up with that? IP Baggage from times before subnet masks? >=20 > >The only known workarounds AFAIK are requiring the client to=20 > default route > >Through the tunnel=20 >=20 > Which causes slowdowns and a huge extra drain on the office's > Internet feed Yes, for most configurations this is true. >=20 > >- or - setup a (persistent?) route on the windows box. >=20 > I suppose we could try a script. >=20 > >Say if client gets 192.168.1.2 when client connects, you=20 > need to manually > >Enter: route -p add 192.168.0.0 mask 255.255.0.0 192.168.1.2 > >On the windows client before connecting. >=20 > Is there a way to fire off a script automatically after connecting? Persistent routes are routes that are reinstalled during bootup. It will just mark them inactive until needed and deactive when no longer = needed. It's a setup that works. '-p' is the persistent flag. >=20 > >Microsoft doesnt seem to be interested in fixing this=20 > problem as the problem > >persist even on Windows XP and has been known since Windows 98(??).=20 >=20 > Figures. >=20 > --Brett >=20 - Sten From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 12:51:15 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ED9A37B401 for ; Thu, 17 Apr 2003 12:51:15 -0700 (PDT) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 240DC43FBD for ; Thu, 17 Apr 2003 12:51:14 -0700 (PDT) (envelope-from sten.daniel.sorsdal@wan.no) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Apr 2003 21:51:02 +0200 Message-ID: <0AF1BBDF1218F14E9B4CCE414744E70F1F3CEC@exchange.wanglobal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Userland PPP/PPTP tunneling problem Thread-Index: AcMFDz5MRcXF+vjbSzGy2EGd4oDv0QACzNWg From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: "Brett Glass" , Subject: RE: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 19:51:15 -0000 >=20 > Oh, and one more question. Suppose we change the LAN which=20 > the client is=20 > tunneling into to a /24. (We can, if we rearrange a few hosts.) Will=20 > Windows then do the right thing? >=20 > --Brett That could work, note that it will only know of that /24 through the = tunnel unless you setup, as mentioned in previous post, a route. - Sten From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 12:52:44 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9798837B401 for ; Thu, 17 Apr 2003 12:52:44 -0700 (PDT) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCC0343FB1 for ; Thu, 17 Apr 2003 12:52:39 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id NAA24716; Thu, 17 Apr 2003 13:52:19 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030417135027.02b1c910@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Apr 2003 13:52:14 -0600 To: Bill Fumerola From: Brett Glass In-Reply-To: <20030417192608.GI47855@elvis.mu.org> References: <4.3.2.7.2.20030417122205.02aed700@localhost> <0AF1BBDF1218F14E9B4CCE414744E70F07DE91@exchange.wanglobal.net> <4.3.2.7.2.20030417122205.02aed700@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" cc: freebsd-net@freebsd.org Subject: Re: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 19:52:44 -0000 At 01:26 PM 4/17/2003, Bill Fumerola wrote: >> I don't understand. Why is /24 more "natural" than /16? > >because that address is in class C space, not class B. read rfc791. As I understand it, that portion of RFC791 was obsolete decades ago. (Even if it weren't, you should be able to subdivide the address space.) --Brett From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 12:59:06 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B60A737B401 for ; Thu, 17 Apr 2003 12:59:06 -0700 (PDT) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC2B243FE5 for ; Thu, 17 Apr 2003 12:59:05 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id NAA24797; Thu, 17 Apr 2003 13:58:59 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030417135646.02af1510@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Apr 2003 13:57:20 -0600 To: Sten Daniel Sørsdal , From: Brett Glass In-Reply-To: <0AF1BBDF1218F14E9B4CCE414744E70F1F3CEB@exchange.wanglobal. net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Subject: RE: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 19:59:07 -0000 At 01:49 PM 4/17/2003, Sten Daniel Sørsdal wrote: >Persistent routes are routes that are reinstalled during bootup. >It will just mark them inactive until needed and deactive when no longer needed. >It's a setup that works. '-p' is the persistent flag. Interesting. Will try this. --Brett From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 13:10:35 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4045C37B401 for ; Thu, 17 Apr 2003 13:10:35 -0700 (PDT) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C3FC43FAF for ; Thu, 17 Apr 2003 13:10:29 -0700 (PDT) (envelope-from sten.daniel.sorsdal@wan.no) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Apr 2003 22:10:18 +0200 Message-ID: <0AF1BBDF1218F14E9B4CCE414744E70F07DE92@exchange.wanglobal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Userland PPP/PPTP tunneling problem Thread-Index: AcMFGuHCtHLJjCOSRQeaZW8Yp0OwLAAAHO8Q From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: "Brett Glass" , "Bill Fumerola" cc: freebsd-net@freebsd.org Subject: RE: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 20:10:35 -0000 >=20 > At 01:26 PM 4/17/2003, Bill Fumerola wrote: > =20 > >> I don't understand. Why is /24 more "natural" than /16? > > > >because that address is in class C space, not class B. read rfc791. >=20 > As I understand it, that portion of RFC791 was obsolete decades ago. > (Even if it weren't, you should be able to subdivide the > address space.) >=20 > --Brett The PPTP protocol allows it (I might be wrong!), the Microsoft PPTP = client does not. It's just a minor problem with this otherwise administrativly easy way = of tunneling. Interesting really, considering Microsoft developed PPTP. If you are going to do this on a large scale, you could use Connection = Manager to build the Profile and add a small batch script to add the route as the tunnel is = being created. - Sten From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 13:25:02 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 750F937B401 for ; Thu, 17 Apr 2003 13:25:02 -0700 (PDT) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83A5143FBD for ; Thu, 17 Apr 2003 13:25:01 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id OAA25130; Thu, 17 Apr 2003 14:24:52 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030417142045.02af5780@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Apr 2003 14:24:45 -0600 To: Sten Daniel Sørsdal , "Bill Fumerola" From: Brett Glass In-Reply-To: <0AF1BBDF1218F14E9B4CCE414744E70F07DE92@exchange.wanglobal. net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org Subject: RE: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 20:25:02 -0000 At 02:10 PM 4/17/2003, Sten Daniel Sørsdal wrote: >The PPTP protocol allows it (I might be wrong!), the Microsoft PPTP client does not. Sounds like Microsoft. You certainly should be allowed to tunnel into any subnet, not just an old-style "Class X" network as a whole. Even if RFC 791 weren't obsolete. The funny thing is that PPP has provisions for this, but Microsoft's PPTP implementation doesn't let you use them. --Brett From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 13:37:18 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77ECA37B40E for ; Thu, 17 Apr 2003 13:37:18 -0700 (PDT) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49EE743F3F for ; Thu, 17 Apr 2003 13:37:17 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id OAA25232; Thu, 17 Apr 2003 14:37:09 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030417143511.02b1d8c0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Apr 2003 14:37:00 -0600 To: Sten Daniel Sørsdal , From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Subject: RE: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 20:37:18 -0000 At 12:18 PM 4/17/2003, Sten Daniel Sørsdal wrote: >Say if client gets 192.168.1.2 when client connects, you need to manually >Enter: route -p add 192.168.0.0 mask 255.255.0.0 192.168.1.2 >On the windows client before connecting. But won't the Windows machine still get the broadcast address wrong? Seems to me that it'd send to 192.168.1.255 instead of 192.168.255.255. --Brett From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 14:48:05 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 844EC37B401 for ; Thu, 17 Apr 2003 14:48:05 -0700 (PDT) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CFB643FBD for ; Thu, 17 Apr 2003 14:48:04 -0700 (PDT) (envelope-from sten.daniel.sorsdal@wan.no) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Apr 2003 23:47:53 +0200 Message-ID: <0AF1BBDF1218F14E9B4CCE414744E70F07DE93@exchange.wanglobal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Userland PPP/PPTP tunneling problem Thread-Index: AcMFIR0z9CXmdR4lR6CCPsFHqmmdwAACGVgQ From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: "Brett Glass" , Subject: RE: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 21:48:05 -0000 > >Say if client gets 192.168.1.2 when client connects, you=20 > need to manually > >Enter: route -p add 192.168.0.0 mask 255.255.0.0 192.168.1.2 > >On the windows client before connecting. >=20 > But won't the Windows machine still get the broadcast address=20 > wrong? Seems > to me that it'd send to 192.168.1.255 instead of 192.168.255.255. >=20 > --Brett It would send to 192.168.1.255 Broadcast and tunneling isnt a good combination, for NetBIOS use WINS. For broadcast to even have the remote chance of working you have to use proxy arp. To proxy arp you have to give the clients a range from the=20 LANs range and add 'enable proxy'. - Sten From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 17:13:59 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 993F337B401; Thu, 17 Apr 2003 17:13:59 -0700 (PDT) Received: from sabre.velocet.net (sabre.velocet.net [216.138.209.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5EFA43FAF; Thu, 17 Apr 2003 17:13:58 -0700 (PDT) (envelope-from dgilbert@velocet.ca) Received: from trooper.velocet.ca (trooper.velocet.net [216.138.242.2]) by sabre.velocet.net (Postfix) with ESMTP id E5670138337; Thu, 17 Apr 2003 20:13:57 -0400 (EDT) Received: by trooper.velocet.ca (Postfix, from userid 66) id 62B7B7490C; Thu, 17 Apr 2003 20:14:04 -0400 (EDT) Received: by canoe.velocet.net (Postfix, from userid 101) id 3AE3156762E; Thu, 17 Apr 2003 20:13:55 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16031.17219.159093.279782@canoe.velocet.net> Date: Thu, 17 Apr 2003 20:13:55 -0400 To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Subject: vlan0 on em0 has mtu 1496 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 00:13:59 -0000 Why does a vlan created against em0 have a mtu of 1496. This is on 4.8-STABLE (cvsup'd this afternoon). Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 17:19:08 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C893437B40E; Thu, 17 Apr 2003 17:19:08 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2898943FAF; Thu, 17 Apr 2003 17:19:08 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h3I0J5Tk024870; Thu, 17 Apr 2003 17:19:05 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h3I0J4Z4024868; Thu, 17 Apr 2003 17:19:04 -0700 Date: Thu, 17 Apr 2003 17:19:04 -0700 From: Brooks Davis To: David Gilbert Message-ID: <20030418001904.GA23983@Odin.AC.HMC.Edu> References: <16031.17219.159093.279782@canoe.velocet.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <16031.17219.159093.279782@canoe.velocet.net> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: freebsd-net@freebsd.org cc: freebsd-stable@freebsd.org Subject: Re: vlan0 on em0 has mtu 1496 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 00:19:09 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 17, 2003 at 08:13:55PM -0400, David Gilbert wrote: > Why does a vlan created against em0 have a mtu of 1496. Because the vlan header takes up 4 bytes. With em(4) devices it looks like fixing that should be a simple matter of raising the real interface's MTU to 1504. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+n0R3XY6L6fI4GtQRAqriAJ4lxpj/hZE0wXPLeihr+9SB7acPcACgpyX5 FPlhf6TVRqlgq6vHs5WXkaQ= =CZqO -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 17:28:32 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2077537B401 for ; Thu, 17 Apr 2003 17:28:32 -0700 (PDT) Received: from pyroxene.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30FB343F93 for ; Thu, 17 Apr 2003 17:28:31 -0700 (PDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by pyroxene.sentex.ca (8.12.9/8.12.8) with ESMTP id h3I0SU8D091507; Thu, 17 Apr 2003 20:28:30 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.2.0.9.0.20030417202920.07adb1e0@marble.sentex.ca> X-Sender: mdtpop@marble.sentex.ca (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 17 Apr 2003 20:34:47 -0400 To: Brooks Davis From: Mike Tancsa In-Reply-To: <20030418001904.GA23983@Odin.AC.HMC.Edu> References: <16031.17219.159093.279782@canoe.velocet.net> <16031.17219.159093.279782@canoe.velocet.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: By Sentex Communications (lava/20020517) cc: freebsd-net@freebsd.org Subject: Re: vlan0 on em0 has mtu 1496 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 00:28:32 -0000 At 05:19 PM 17/04/2003 -0700, Brooks Davis wrote: >On Thu, Apr 17, 2003 at 08:13:55PM -0400, David Gilbert wrote: > > Why does a vlan created against em0 have a mtu of 1496. > >Because the vlan header takes up 4 bytes. With em(4) devices it looks >like fixing that should be a simple matter of raising the real >interface's MTU to 1504. Why the difference in behavior vs how the fxp driver works with respect to vlans ? ---Mike From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 17:40:18 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C905637B401 for ; Thu, 17 Apr 2003 17:40:18 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C9B543FD7 for ; Thu, 17 Apr 2003 17:40:18 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h3I0eATk029668; Thu, 17 Apr 2003 17:40:11 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h3I0eAXP029667; Thu, 17 Apr 2003 17:40:10 -0700 Date: Thu, 17 Apr 2003 17:40:10 -0700 From: Brooks Davis To: Mike Tancsa Message-ID: <20030418004010.GA25152@Odin.AC.HMC.Edu> References: <16031.17219.159093.279782@canoe.velocet.net> <16031.17219.159093.279782@canoe.velocet.net> <5.2.0.9.0.20030417202920.07adb1e0@marble.sentex.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <5.2.0.9.0.20030417202920.07adb1e0@marble.sentex.ca> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: freebsd-net@freebsd.org Subject: Re: vlan0 on em0 has mtu 1496 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 00:40:19 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 17, 2003 at 08:34:47PM -0400, Mike Tancsa wrote: > At 05:19 PM 17/04/2003 -0700, Brooks Davis wrote: > >On Thu, Apr 17, 2003 at 08:13:55PM -0400, David Gilbert wrote: > >> Why does a vlan created against em0 have a mtu of 1496. > > > >Because the vlan header takes up 4 bytes. With em(4) devices it looks > >like fixing that should be a simple matter of raising the real > >interface's MTU to 1504. >=20 > Why the difference in behavior vs how the fxp driver works with respect t= o=20 > vlans ? I don't know. In current both have the VLAN_MTU capability set, but I don't seem to be getting consistant results from 4.x systems. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+n0loXY6L6fI4GtQRAnCSAKDLR+0kQYdY9/blLt83sdiKRtCquwCfaJQ8 /m0rHi8ui0o3oYXHI2rYx1w= =nEOg -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 17:50:34 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1F0A37B401; Thu, 17 Apr 2003 17:50:34 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2A3443FA3; Thu, 17 Apr 2003 17:50:31 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h3I0oUmA033278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Apr 2003 20:50:31 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id h3I0oUbg033275; Thu, 17 Apr 2003 20:50:30 -0400 (EDT) (envelope-from wollman) Date: Thu, 17 Apr 2003 20:50:30 -0400 (EDT) From: Garrett Wollman Message-Id: <200304180050.h3I0oUbg033275@khavrinen.lcs.mit.edu> To: Brooks Davis In-Reply-To: <20030418001904.GA23983@Odin.AC.HMC.Edu> References: <16031.17219.159093.279782@canoe.velocet.net> <20030418001904.GA23983@Odin.AC.HMC.Edu> cc: freebsd-net@freebsd.org cc: freebsd-stable@freebsd.org Subject: Re: vlan0 on em0 has mtu 1496 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 00:50:35 -0000 < said: > Because the vlan header takes up 4 bytes. With em(4) devices it looks > like fixing that should be a simple matter of raising the real > interface's MTU to 1504. Actually, the parent interface's MTU should not be touched. The link-layer header length is what needs to be increased. -GAWollman From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 19:26:12 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8BF937B401 for ; Thu, 17 Apr 2003 19:26:11 -0700 (PDT) Received: from www.ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 467A043FDD for ; Thu, 17 Apr 2003 19:26:11 -0700 (PDT) (envelope-from ambrisko@www.ambrisko.com) Received: from www.ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.8p1/8.12.8) with ESMTP id h3I2QAO7099874; Thu, 17 Apr 2003 19:26:10 -0700 (PDT) (envelope-from ambrisko@www.ambrisko.com) Received: (from ambrisko@localhost) by www.ambrisko.com (8.12.8p1/8.12.8/Submit) id h3I2QAu1099873; Thu, 17 Apr 2003 19:26:10 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200304180226.h3I2QAu1099873@www.ambrisko.com> In-Reply-To: <20030418004010.GA25152@Odin.AC.HMC.Edu> To: Brooks Davis Date: Thu, 17 Apr 2003 19:26:10 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org cc: Mike Tancsa Subject: Re: vlan0 on em0 has mtu 1496 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 02:26:12 -0000 Brooks Davis writes: -- Start of PGP signed section. | On Thu, Apr 17, 2003 at 08:34:47PM -0400, Mike Tancsa wrote: | > At 05:19 PM 17/04/2003 -0700, Brooks Davis wrote: | > >On Thu, Apr 17, 2003 at 08:13:55PM -0400, David Gilbert wrote: | > >> Why does a vlan created against em0 have a mtu of 1496. | > > | > >Because the vlan header takes up 4 bytes. With em(4) devices it looks | > >like fixing that should be a simple matter of raising the real | > >interface's MTU to 1504. | > | > Why the difference in behavior vs how the fxp driver works with respect to | > vlans ? | | I don't know. In current both have the VLAN_MTU capability set, but I | don't seem to be getting consistant results from 4.x systems. I think it needs this: #if __FreeBSD_version >= 500000 ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING | IFCAP_VLAN_MTU; #endif changed to: /* * Tell the upper layer(s) we support long frames. */ ifp->if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); #if __FreeBSD_version >= 500000 ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING | IFCAP_VLAN_MTU; #endif to work for both -stable and -current. Tomorrow I can test it out at work, if someone beats me to it and commit it that's fine. Doug A. From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 19:43:46 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68FBC37B404; Thu, 17 Apr 2003 19:43:46 -0700 (PDT) Received: from sabre.velocet.net (sabre.velocet.net [216.138.209.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F28E43F3F; Thu, 17 Apr 2003 19:43:45 -0700 (PDT) (envelope-from dgilbert@velocet.ca) Received: from trooper.velocet.ca (trooper.velocet.net [216.138.242.2]) by sabre.velocet.net (Postfix) with ESMTP id 23F541381F8; Thu, 17 Apr 2003 22:43:41 -0400 (EDT) Received: by trooper.velocet.ca (Postfix, from userid 66) id 852537490C; Thu, 17 Apr 2003 22:43:37 -0400 (EDT) Received: by canoe.velocet.net (Postfix, from userid 101) id B712056762E; Thu, 17 Apr 2003 21:10:31 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16031.20615.585606.881893@canoe.velocet.net> Date: Thu, 17 Apr 2003 21:10:31 -0400 To: Brooks Davis In-Reply-To: <20030418001904.GA23983@Odin.AC.HMC.Edu> References: <16031.17219.159093.279782@canoe.velocet.net> <20030418001904.GA23983@Odin.AC.HMC.Edu> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid cc: freebsd-net@freebsd.org cc: David Gilbert cc: freebsd-stable@freebsd.org Subject: Re: vlan0 on em0 has mtu 1496 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 02:43:46 -0000 >>>>> "Brooks" == Brooks Davis writes: Brooks> On Thu, Apr 17, 2003 at 08:13:55PM -0400, David Gilbert wrote: >> Why does a vlan created against em0 have a mtu of 1496. Brooks> Because the vlan header takes up 4 bytes. With em(4) devices Brooks> it looks like fixing that should be a simple matter of raising Brooks> the real interface's MTU to 1504. On many cards, like the fxp, the ability to send 1526 byte packets (which include vlan) is encoded in the header size abilities of the card, not the mtu. It would seem that em is missing this. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 10:17:51 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D532037B401 for ; Fri, 18 Apr 2003 10:17:50 -0700 (PDT) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B66FE43FEA for ; Fri, 18 Apr 2003 10:17:49 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id LAA04993; Fri, 18 Apr 2003 11:17:41 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030418111623.02819bd0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Apr 2003 11:17:36 -0600 To: Sten Daniel Sørsdal , From: Brett Glass In-Reply-To: <0AF1BBDF1218F14E9B4CCE414744E70F07DE93@exchange.wanglobal. net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Subject: RE: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 17:17:52 -0000 At 03:47 PM 4/17/2003, Sten Daniel Sørsdal wrote: >> >Say if client gets 192.168.1.2 when client connects, you >> need to manually >> >Enter: route -p add 192.168.0.0 mask 255.255.0.0 192.168.1.2 >> >On the windows client before connecting. >> >> But won't the Windows machine still get the broadcast address >> wrong? Seems >> to me that it'd send to 192.168.1.255 instead of 192.168.255.255. >> >> --Brett > >It would send to 192.168.1.255 Yep, and miss the boat. >Broadcast and tunneling isnt a good combination, Yes, but broadcast is needed for ARP. To tunnel effectively, you need to be able to ARP (for example) the printer on the LAN you're tunneling into. --Brett From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 10:50:37 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3C3837B401 for ; Fri, 18 Apr 2003 10:50:36 -0700 (PDT) Received: from mail.parodius.com (mail.parodius.com [64.71.184.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59A5643FAF for ; Fri, 18 Apr 2003 10:50:36 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.9/8.12.9) with ESMTP id h3IHnujU072222 for ; Fri, 18 Apr 2003 10:49:56 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.9/8.12.9/Submit) id h3IHnuxK072221 for freebsd-net@freebsd.org; Fri, 18 Apr 2003 10:49:56 -0700 (PDT) Date: Fri, 18 Apr 2003 10:49:56 -0700 From: Jeremy Chadwick To: freebsd-net@freebsd.org Message-ID: <20030418174956.GA71335@parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 17:50:37 -0000 Greetings. I've spoken with numerous other administrators about the phenomenon I'm about to post, and the only answer I've gotten so far is "Your box is broken" (how quaint). I have two web/nameservers, both which exhibit this behaviour. There's much mystery involved in this problem, so this post will be long and verbose. The problem: BIND-8 looks to be sending packets destined for my RFC 1918 subnet (10.0.0.0/8) over my _WAN interface_. Since I have overly anal firewall rules to block this sort-of thing, what I see numerous times a day (at irregular intervals) are _outgoing_ packets being blocked. First, let's start with the machine NIC/network topology. There are two physical NICs in my nameservers: one public interface and one private, using entirely separate switches to segregate the traffic. The public interface NIC has multiple IPs assigned to it (IP aliases). Here's ifconfig: fxp0: flags=8843 mtu 1500 inet 64.71.184.170 netmask 0xffffffe0 broadcast 64.71.184.191 inet 64.71.184.171 netmask 0xffffffff broadcast 64.71.184.171 inet 64.71.184.172 netmask 0xffffffff broadcast 64.71.184.172 inet 64.71.184.173 netmask 0xffffffff broadcast 64.71.184.173 inet 64.71.184.175 netmask 0xffffffff broadcast 64.71.184.175 inet 64.71.184.176 netmask 0xffffffff broadcast 64.71.184.176 inet 64.71.184.177 netmask 0xffffffff broadcast 64.71.184.177 inet 64.71.184.178 netmask 0xffffffff broadcast 64.71.184.178 inet 64.71.184.179 netmask 0xffffffff broadcast 64.71.184.179 ether 00:e0:81:02:3c:88 media: Ethernet autoselect (100baseTX ) status: active fxp1: flags=8843 mtu 1500 inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255 ether 00:e0:81:02:3c:89 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 My routing table: Internet: Destination Gateway Flags Refs Use Netif Expire default 64.71.184.161 UGSc 63 109070 fxp0 10 link#2 UC 3 0 fxp1 10.0.0.2 00:e0:81:04:69:e2 UHLW 8 1263590 fxp1 1053 10.0.0.128 00:04:ea:9c:2d:c1 UHLW 0 14822 fxp1 966 10.0.0.129 00:c0:05:01:60:fe UHLW 0 263 fxp1 1023 64.71.184.160/27 link#1 UC 5 0 fxp0 64.71.184.161 00:03:6b:50:1a:21 UHLW 62 0 fxp0 978 64.71.184.162 00:90:27:e0:0f:70 UHLW 0 2 fxp0 1053 64.71.184.170 00:e0:81:02:3c:88 UHLW 0 25583 lo0 64.71.184.171/32 link#1 UC 0 0 fxp0 64.71.184.172/32 link#1 UC 0 0 fxp0 64.71.184.173/32 link#1 UC 0 0 fxp0 64.71.184.175/32 link#1 UC 0 0 fxp0 64.71.184.176/32 link#1 UC 0 0 fxp0 64.71.184.177/32 link#1 UC 0 0 fxp0 64.71.184.178 00:e0:81:02:3c:88 UHLW 0 19203 lo0 => 64.71.184.178/32 link#1 UC 1 0 fxp0 64.71.184.179/32 link#1 UC 0 0 fxp0 64.71.184.189 00:e0:81:04:69:e1 UHLW 0 99 fxp0 64.71.184.190 link#1 UHLW 1 12 fxp0 127.0.0.1 127.0.0.1 UH 2 246142 lo0 My firewalling rules are set up as follows (please note rule 400, and the packet counters on rule 1005): 00100 580884 73786974 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 2507920 940337032 allow ip from any to any via fxp1 01000 0 0 deny log ip from any to 10.0.0.0/8 in recv fxp0 01005 195 52392 deny log ip from 10.0.0.0/8 to any out xmit fxp0 01100 0 0 deny log ip from any to 172.16.0.0/12 in recv fxp0 01105 0 0 deny log ip from 172.16.0.0/12 to any out xmit fxp0 01200 0 0 deny log ip from any to 192.168.0.0/16 in recv fxp0 01205 0 0 deny log ip from 192.168.0.0/16 to any out xmit fxp0 syslog security shows the following for the denied on rule 1005 (this is just a snippet): Apr 18 08:53:45 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 64.71.184.190:53 out via fxp0 Apr 18 09:35:13 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 64.71.184.190:53 out via fxp0 Apr 18 10:01:21 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 64.71.184.190:53 out via fxp0 syslog for named shows corresponding entries, verifying that BIND does look to be sending things out on the wrong interface (the entries below report Permission denied due to my firewalling rules above): Apr 18 08:53:45 pentarou named[49497]: ns_req: sendto([64.71.184.190].53): Permission denied Apr 18 09:35:13 pentarou named[49497]: ns_req: sendto([64.71.184.190].53): Permission denied Apr 18 10:01:21 pentarou named[49497]: ns_req: sendto([64.71.184.190].53): Permission denied What is happening should not even be technically possible, if I understand things correctly. Applicable pieces of my BIND-8 configuration are as follows: options { query-source address 64.71.184.171; transfer-source 10.0.0.1; listen-on { 127.0.0.1; 10.0.0.1; 64.71.184.171; }; }; Then, in zones I wish to slave via the WAN interface, I insert the following into the zone block (example included): zone "malkavian.com" in { type slave; notify no; file "../zones/zone.malkavian.com"; allow-transfer { 216.66.32.72; }; masters { 216.66.32.72; }; transfer-source 64.71.184.171; }; Non-WAN zones (which should be transferred over the private interface) look to be as follows (I use TSIG just because): zone "deltaplayer.com" in { type master; file "../zones/zone.deltaplayer.com"; allow-transfer { key pentarou-gabriel-LAN; }; }; I'd also like to throw in the fact that I have tried BIND-9 on this exact setup, adding "notify-source" entries where appropriate, and I _still witnessed the same behaviour_ (and on a much larger scale none the less!). Finally, here's the twist which makes absolutely no sense to me what-so-ever: To try and find out what sort-of packets were being sent across the WAN with a src address of 10.0.0.1, I ran tcpdump as follows, and went to bed for about 8 hours: $ tcpdump -p -ifxp0 -l -n -s8192 -X "src net 10.0.0.0/8" During those 8 hours, ipfw reported numerous outgoing packets being blocked (rule 1005) -- but tcpdump showed _absolutely nothing_. I'd _REALLY_ love to get to the bottom of this, as there is obviously a bug somewhere, and I have a feeling this kind-of issue could easily become one of folks saying "BIND is buggy" and the ISC folks saying "FreeBSD is broken." Advice/comments/questions would be greatly appreciated, as I'm extremely frustrated with this entire situation, and not sure where to turn. Thanks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 10:51:04 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B34C37B401 for ; Fri, 18 Apr 2003 10:51:04 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8B8F43FBF for ; Fri, 18 Apr 2003 10:51:03 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h3IHp1Vh004854 for ; Fri, 18 Apr 2003 19:51:02 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Fri, 18 Apr 2003 19:51:01 +0200 (CEST) From: Martin Blapp To: freebsd-net@freebsd.org Message-ID: <20030418193305.S6156@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Implementing SO_BINDTODEVICE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 17:51:04 -0000 Hi all, How difficult would it be to implement SO_BINDTODEVICE on FreeBSD ? I need the to make is possible to run more than one instance of dhclient on one host with more than one NIC. We would need this to support removable devices properly. There is a tool called omshell which should be able to change variables so the interface is added to the lists. Unfortunatly the documentation is bad and I only found hooks to dhcpd. Martin Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 13:09:37 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E31737B401 for ; Fri, 18 Apr 2003 13:09:37 -0700 (PDT) Received: from web10410.mail.yahoo.com (web10410.mail.yahoo.com [216.136.128.123]) by mx1.FreeBSD.org (Postfix) with SMTP id D915443FB1 for ; Fri, 18 Apr 2003 13:09:36 -0700 (PDT) (envelope-from opolyakov@yahoo.com) Message-ID: <20030418200936.82331.qmail@web10410.mail.yahoo.com> Received: from [67.112.212.200] by web10410.mail.yahoo.com via HTTP; Fri, 18 Apr 2003 13:09:36 PDT Date: Fri, 18 Apr 2003 13:09:36 -0700 (PDT) From: Oleg Polyakov To: Jeremy Chadwick , freebsd-net@freebsd.org In-Reply-To: <20030418174956.GA71335@parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 20:09:37 -0000 You may want to comment out line: // transfer-source 10.0.0.1; Transfers to 10.0.0.0 should choose address 10.0.0.1 automagically. Transfers elsewhere should use zone-relevant transfer-source option. --- Jeremy Chadwick wrote: > Greetings. I've spoken with numerous other administrators > about the phenomenon I'm about to post, and the only answer > I've gotten so far is "Your box is broken" (how quaint). I > have two web/nameservers, both which exhibit this behaviour. > There's much mystery involved in this problem, so this post > will be long and verbose. > > The problem: BIND-8 looks to be sending packets destined for > my RFC 1918 subnet (10.0.0.0/8) over my _WAN interface_. > Since I have overly anal firewall rules to block this sort-of > thing, what I see numerous times a day (at irregular intervals) > are _outgoing_ packets being blocked. > > First, let's start with the machine NIC/network topology. There > are two physical NICs in my nameservers: one public interface > and one private, using entirely separate switches to segregate > the traffic. The public interface NIC has multiple IPs assigned > to it (IP aliases). Here's ifconfig: > > fxp0: flags=8843 mtu 1500 > inet 64.71.184.170 netmask 0xffffffe0 broadcast 64.71.184.191 > inet 64.71.184.171 netmask 0xffffffff broadcast 64.71.184.171 > inet 64.71.184.172 netmask 0xffffffff broadcast 64.71.184.172 > inet 64.71.184.173 netmask 0xffffffff broadcast 64.71.184.173 > inet 64.71.184.175 netmask 0xffffffff broadcast 64.71.184.175 > inet 64.71.184.176 netmask 0xffffffff broadcast 64.71.184.176 > inet 64.71.184.177 netmask 0xffffffff broadcast 64.71.184.177 > inet 64.71.184.178 netmask 0xffffffff broadcast 64.71.184.178 > inet 64.71.184.179 netmask 0xffffffff broadcast 64.71.184.179 > ether 00:e0:81:02:3c:88 > media: Ethernet autoselect (100baseTX ) > status: active > fxp1: flags=8843 mtu 1500 > inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255 > ether 00:e0:81:02:3c:89 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > > My routing table: > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 64.71.184.161 UGSc 63 109070 fxp0 > 10 link#2 UC 3 0 fxp1 > 10.0.0.2 00:e0:81:04:69:e2 UHLW 8 1263590 fxp1 1053 > 10.0.0.128 00:04:ea:9c:2d:c1 UHLW 0 14822 fxp1 966 > 10.0.0.129 00:c0:05:01:60:fe UHLW 0 263 fxp1 1023 > 64.71.184.160/27 link#1 UC 5 0 fxp0 > 64.71.184.161 00:03:6b:50:1a:21 UHLW 62 0 fxp0 978 > 64.71.184.162 00:90:27:e0:0f:70 UHLW 0 2 fxp0 1053 > 64.71.184.170 00:e0:81:02:3c:88 UHLW 0 25583 lo0 > 64.71.184.171/32 link#1 UC 0 0 fxp0 > 64.71.184.172/32 link#1 UC 0 0 fxp0 > 64.71.184.173/32 link#1 UC 0 0 fxp0 > 64.71.184.175/32 link#1 UC 0 0 fxp0 > 64.71.184.176/32 link#1 UC 0 0 fxp0 > 64.71.184.177/32 link#1 UC 0 0 fxp0 > 64.71.184.178 00:e0:81:02:3c:88 UHLW 0 19203 lo0 => > 64.71.184.178/32 link#1 UC 1 0 fxp0 > 64.71.184.179/32 link#1 UC 0 0 fxp0 > 64.71.184.189 00:e0:81:04:69:e1 UHLW 0 99 fxp0 > 64.71.184.190 link#1 UHLW 1 12 fxp0 > 127.0.0.1 127.0.0.1 UH 2 246142 lo0 > > My firewalling rules are set up as follows (please note rule 400, > and the packet counters on rule 1005): > > 00100 580884 73786974 allow ip from any to any via lo0 > 00200 0 0 deny ip from any to 127.0.0.0/8 > 00300 0 0 deny ip from 127.0.0.0/8 to any > 00400 2507920 940337032 allow ip from any to any via fxp1 > 01000 0 0 deny log ip from any to 10.0.0.0/8 in recv fxp0 > 01005 195 52392 deny log ip from 10.0.0.0/8 to any out xmit fxp0 > 01100 0 0 deny log ip from any to 172.16.0.0/12 in recv fxp0 > 01105 0 0 deny log ip from 172.16.0.0/12 to any out xmit > fxp0 > 01200 0 0 deny log ip from any to 192.168.0.0/16 in recv > fxp0 > 01205 0 0 deny log ip from 192.168.0.0/16 to any out xmit > fxp0 > > syslog security shows the following for the denied on rule 1005 > (this is just a snippet): > > Apr 18 08:53:45 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 > 64.71.184.190:53 out via fxp0 > Apr 18 09:35:13 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 > 64.71.184.190:53 out via fxp0 > Apr 18 10:01:21 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 > 64.71.184.190:53 out via fxp0 > > syslog for named shows corresponding entries, verifying that BIND > does look to be sending things out on the wrong interface (the > entries below report Permission denied due to my firewalling > rules above): > > Apr 18 08:53:45 pentarou named[49497]: ns_req: sendto([64.71.184.190].53): > Permission denied > Apr 18 09:35:13 pentarou named[49497]: ns_req: sendto([64.71.184.190].53): > Permission denied > Apr 18 10:01:21 pentarou named[49497]: ns_req: sendto([64.71.184.190].53): > Permission denied > > What is happening should not even be technically possible, if I > understand things correctly. > > Applicable pieces of my BIND-8 configuration are as follows: > > options { > query-source address 64.71.184.171; > transfer-source 10.0.0.1; > > listen-on { > 127.0.0.1; > 10.0.0.1; > 64.71.184.171; > }; > }; > > Then, in zones I wish to slave via the WAN interface, I insert > the following into the zone block (example included): > > zone "malkavian.com" in { > type slave; > notify no; > file "../zones/zone.malkavian.com"; > allow-transfer { 216.66.32.72; }; > masters { 216.66.32.72; }; > transfer-source 64.71.184.171; > }; > > Non-WAN zones (which should be transferred over the private > interface) look to be as follows (I use TSIG just because): > > zone "deltaplayer.com" in { > type master; > file "../zones/zone.deltaplayer.com"; > allow-transfer { key pentarou-gabriel-LAN; }; > }; > > I'd also like to throw in the fact that I have tried BIND-9 > on this exact setup, adding "notify-source" entries where > appropriate, and I _still witnessed the same behaviour_ (and > on a much larger scale none the less!). > > Finally, here's the twist which makes absolutely no sense > to me what-so-ever: > > To try and find out what sort-of packets were being sent > across the WAN with a src address of 10.0.0.1, I ran tcpdump > as follows, and went to bed for about 8 hours: > > $ tcpdump -p -ifxp0 -l -n -s8192 -X "src net 10.0.0.0/8" > > During those 8 hours, ipfw reported numerous outgoing packets > being blocked (rule 1005) -- but tcpdump showed _absolutely > nothing_. > > I'd _REALLY_ love to get to the bottom of this, as there is > obviously a bug somewhere, and I have a feeling this kind-of > issue could easily become one of folks saying "BIND is buggy" > and the ISC folks saying "FreeBSD is broken." > > Advice/comments/questions would be greatly appreciated, as > I'm extremely frustrated with this entire situation, and not > sure where to turn. > > Thanks. > > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. | > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 13:17:26 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95C9337B401 for ; Fri, 18 Apr 2003 13:17:26 -0700 (PDT) Received: from mail.parodius.com (mail.parodius.com [64.71.184.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id C829243F3F for ; Fri, 18 Apr 2003 13:17:25 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.9/8.12.9) with ESMTP id h3IKGjjU078208 for ; Fri, 18 Apr 2003 13:16:45 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.9/8.12.9/Submit) id h3IKGjfL078207 for freebsd-net@freebsd.org; Fri, 18 Apr 2003 13:16:45 -0700 (PDT) Date: Fri, 18 Apr 2003 13:16:45 -0700 From: Jeremy Chadwick To: freebsd-net@freebsd.org Message-ID: <20030418201645.GA77986@parodius.com> References: <20030418174956.GA71335@parodius.com> <20030418200936.82331.qmail@web10410.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030418200936.82331.qmail@web10410.mail.yahoo.com> User-Agent: Mutt/1.5.4i Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 20:17:26 -0000 Oleg: I tried your recommendation of commenting out the transfer-source line, and within a few moments of running this: ipfw zero 1005 && ndc stop && /usr/sbin/named -u bind -g bind ...saw the following in our security syslog: Apr 18 13:11:09 pentarou /kernel: ipfw: Entry 1005 cleared. Apr 18 13:11:33 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 64.71.184.190:53 out via fxp0 Apr 18 13:12:04 pentarou last message repeated 5 times ...and our named syslog: Apr 18 13:11:33 pentarou named[77949]: ns_req: sendto([64.71.184.190].53): Permission denied So, it doesn't look like that's the offender. :-) By the way, something I didn't cover: 64.71.184.190 is our secondary nameserver's WAN IP. It's private is 10.0.0.2. I'm still wondering why tcpdump isn't catching the I/O... -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Fri, Apr 18, 2003 at 01:09:36PM -0700, Oleg Polyakov wrote: > You may want to comment out line: > // transfer-source 10.0.0.1; > > Transfers to 10.0.0.0 should choose address 10.0.0.1 automagically. > Transfers elsewhere should use zone-relevant transfer-source option. > > --- Jeremy Chadwick wrote: > > Greetings. I've spoken with numerous other administrators > > about the phenomenon I'm about to post, and the only answer > > I've gotten so far is "Your box is broken" (how quaint). I > > have two web/nameservers, both which exhibit this behaviour. > > There's much mystery involved in this problem, so this post > > will be long and verbose. > > > > The problem: BIND-8 looks to be sending packets destined for > > my RFC 1918 subnet (10.0.0.0/8) over my _WAN interface_. > > Since I have overly anal firewall rules to block this sort-of > > thing, what I see numerous times a day (at irregular intervals) > > are _outgoing_ packets being blocked. > > > > First, let's start with the machine NIC/network topology. There > > are two physical NICs in my nameservers: one public interface > > and one private, using entirely separate switches to segregate > > the traffic. The public interface NIC has multiple IPs assigned > > to it (IP aliases). Here's ifconfig: > > > > fxp0: flags=8843 mtu 1500 > > inet 64.71.184.170 netmask 0xffffffe0 broadcast 64.71.184.191 > > inet 64.71.184.171 netmask 0xffffffff broadcast 64.71.184.171 > > inet 64.71.184.172 netmask 0xffffffff broadcast 64.71.184.172 > > inet 64.71.184.173 netmask 0xffffffff broadcast 64.71.184.173 > > inet 64.71.184.175 netmask 0xffffffff broadcast 64.71.184.175 > > inet 64.71.184.176 netmask 0xffffffff broadcast 64.71.184.176 > > inet 64.71.184.177 netmask 0xffffffff broadcast 64.71.184.177 > > inet 64.71.184.178 netmask 0xffffffff broadcast 64.71.184.178 > > inet 64.71.184.179 netmask 0xffffffff broadcast 64.71.184.179 > > ether 00:e0:81:02:3c:88 > > media: Ethernet autoselect (100baseTX ) > > status: active > > fxp1: flags=8843 mtu 1500 > > inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255 > > ether 00:e0:81:02:3c:89 > > media: Ethernet autoselect (100baseTX ) > > status: active > > lo0: flags=8049 mtu 16384 > > inet 127.0.0.1 netmask 0xff000000 > > > > My routing table: > > > > Internet: > > Destination Gateway Flags Refs Use Netif Expire > > default 64.71.184.161 UGSc 63 109070 fxp0 > > 10 link#2 UC 3 0 fxp1 > > 10.0.0.2 00:e0:81:04:69:e2 UHLW 8 1263590 fxp1 1053 > > 10.0.0.128 00:04:ea:9c:2d:c1 UHLW 0 14822 fxp1 966 > > 10.0.0.129 00:c0:05:01:60:fe UHLW 0 263 fxp1 1023 > > 64.71.184.160/27 link#1 UC 5 0 fxp0 > > 64.71.184.161 00:03:6b:50:1a:21 UHLW 62 0 fxp0 978 > > 64.71.184.162 00:90:27:e0:0f:70 UHLW 0 2 fxp0 1053 > > 64.71.184.170 00:e0:81:02:3c:88 UHLW 0 25583 lo0 > > 64.71.184.171/32 link#1 UC 0 0 fxp0 > > 64.71.184.172/32 link#1 UC 0 0 fxp0 > > 64.71.184.173/32 link#1 UC 0 0 fxp0 > > 64.71.184.175/32 link#1 UC 0 0 fxp0 > > 64.71.184.176/32 link#1 UC 0 0 fxp0 > > 64.71.184.177/32 link#1 UC 0 0 fxp0 > > 64.71.184.178 00:e0:81:02:3c:88 UHLW 0 19203 lo0 => > > 64.71.184.178/32 link#1 UC 1 0 fxp0 > > 64.71.184.179/32 link#1 UC 0 0 fxp0 > > 64.71.184.189 00:e0:81:04:69:e1 UHLW 0 99 fxp0 > > 64.71.184.190 link#1 UHLW 1 12 fxp0 > > 127.0.0.1 127.0.0.1 UH 2 246142 lo0 > > > > My firewalling rules are set up as follows (please note rule 400, > > and the packet counters on rule 1005): > > > > 00100 580884 73786974 allow ip from any to any via lo0 > > 00200 0 0 deny ip from any to 127.0.0.0/8 > > 00300 0 0 deny ip from 127.0.0.0/8 to any > > 00400 2507920 940337032 allow ip from any to any via fxp1 > > 01000 0 0 deny log ip from any to 10.0.0.0/8 in recv fxp0 > > 01005 195 52392 deny log ip from 10.0.0.0/8 to any out xmit fxp0 > > 01100 0 0 deny log ip from any to 172.16.0.0/12 in recv fxp0 > > 01105 0 0 deny log ip from 172.16.0.0/12 to any out xmit > > fxp0 > > 01200 0 0 deny log ip from any to 192.168.0.0/16 in recv > > fxp0 > > 01205 0 0 deny log ip from 192.168.0.0/16 to any out xmit > > fxp0 > > > > syslog security shows the following for the denied on rule 1005 > > (this is just a snippet): > > > > Apr 18 08:53:45 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 > > 64.71.184.190:53 out via fxp0 > > Apr 18 09:35:13 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 > > 64.71.184.190:53 out via fxp0 > > Apr 18 10:01:21 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 > > 64.71.184.190:53 out via fxp0 > > > > syslog for named shows corresponding entries, verifying that BIND > > does look to be sending things out on the wrong interface (the > > entries below report Permission denied due to my firewalling > > rules above): > > > > Apr 18 08:53:45 pentarou named[49497]: ns_req: sendto([64.71.184.190].53): > > Permission denied > > Apr 18 09:35:13 pentarou named[49497]: ns_req: sendto([64.71.184.190].53): > > Permission denied > > Apr 18 10:01:21 pentarou named[49497]: ns_req: sendto([64.71.184.190].53): > > Permission denied > > > > What is happening should not even be technically possible, if I > > understand things correctly. > > > > Applicable pieces of my BIND-8 configuration are as follows: > > > > options { > > query-source address 64.71.184.171; > > transfer-source 10.0.0.1; > > > > listen-on { > > 127.0.0.1; > > 10.0.0.1; > > 64.71.184.171; > > }; > > }; > > > > Then, in zones I wish to slave via the WAN interface, I insert > > the following into the zone block (example included): > > > > zone "malkavian.com" in { > > type slave; > > notify no; > > file "../zones/zone.malkavian.com"; > > allow-transfer { 216.66.32.72; }; > > masters { 216.66.32.72; }; > > transfer-source 64.71.184.171; > > }; > > > > Non-WAN zones (which should be transferred over the private > > interface) look to be as follows (I use TSIG just because): > > > > zone "deltaplayer.com" in { > > type master; > > file "../zones/zone.deltaplayer.com"; > > allow-transfer { key pentarou-gabriel-LAN; }; > > }; > > > > I'd also like to throw in the fact that I have tried BIND-9 > > on this exact setup, adding "notify-source" entries where > > appropriate, and I _still witnessed the same behaviour_ (and > > on a much larger scale none the less!). > > > > Finally, here's the twist which makes absolutely no sense > > to me what-so-ever: > > > > To try and find out what sort-of packets were being sent > > across the WAN with a src address of 10.0.0.1, I ran tcpdump > > as follows, and went to bed for about 8 hours: > > > > $ tcpdump -p -ifxp0 -l -n -s8192 -X "src net 10.0.0.0/8" > > > > During those 8 hours, ipfw reported numerous outgoing packets > > being blocked (rule 1005) -- but tcpdump showed _absolutely > > nothing_. > > > > I'd _REALLY_ love to get to the bottom of this, as there is > > obviously a bug somewhere, and I have a feeling this kind-of > > issue could easily become one of folks saying "BIND is buggy" > > and the ISC folks saying "FreeBSD is broken." > > > > Advice/comments/questions would be greatly appreciated, as > > I'm extremely frustrated with this entire situation, and not > > sure where to turn. > > > > Thanks. > > > > -- > > | Jeremy Chadwick jdc@parodius.com | > > | Parodius Networking http://www.parodius.com/ | > > | UNIX Systems Administrator Mountain View, CA, USA | > > | Making life hard for others since 1977. | > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo > http://search.yahoo.com > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 14:54:01 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74A4037B401 for ; Fri, 18 Apr 2003 14:54:01 -0700 (PDT) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 122F443FAF for ; Fri, 18 Apr 2003 14:54:00 -0700 (PDT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 70136 invoked from network); 18 Apr 2003 22:11:36 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 18 Apr 2003 22:11:36 -0000 Received: (nullmailer pid 668 invoked by uid 136); Fri, 18 Apr 2003 21:56:56 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20030418201645.GA77986@parodius.com> To: Jeremy Chadwick Date: Sat, 19 Apr 2003 01:56:56 +0400 (MSD) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1050703016.604363.667.nullmailer@cicuta.babolo.ru> cc: freebsd-net@freebsd.org Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 21:54:01 -0000 > > By the way, something I didn't cover: 64.71.184.190 is our > secondary nameserver's WAN IP. It's private is 10.0.0.2. That can be the key - if secondary server request your private master using public IP > I'm still wondering why tcpdump isn't catching the I/O... Your ipfw rules forbid packets before interface you are looking for. Just ipfw forward them to another interface to catch them. From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 15:02:33 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C0EC37B401 for ; Fri, 18 Apr 2003 15:02:33 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id B956143F75 for ; Fri, 18 Apr 2003 15:02:32 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org (12-234-159-107.client.attbi.com[12.234.159.107]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <2003041822023100100a3tute>; Fri, 18 Apr 2003 22:02:31 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.8p1/8.12.3) with ESMTP id h3IM2Uki040305; Fri, 18 Apr 2003 15:02:30 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.8p1/8.12.8/Submit) id h3IM2TLg040304; Fri, 18 Apr 2003 15:02:29 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Fri, 18 Apr 2003 15:02:29 -0700 From: "Crist J. Clark" To: Jeremy Chadwick Message-ID: <20030418220229.GB39466@blossom.cjclark.org> References: <20030418174956.GA71335@parodius.com> <20030418200936.82331.qmail@web10410.mail.yahoo.com> <20030418201645.GA77986@parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030418201645.GA77986@parodius.com> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-net@freebsd.org Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 22:02:33 -0000 On Fri, Apr 18, 2003 at 01:16:45PM -0700, Jeremy Chadwick wrote: > Oleg: > > I tried your recommendation of commenting out the transfer-source > line, and within a few moments of running this: > > ipfw zero 1005 && ndc stop && /usr/sbin/named -u bind -g bind > > ...saw the following in our security syslog: > > Apr 18 13:11:09 pentarou /kernel: ipfw: Entry 1005 cleared. > Apr 18 13:11:33 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 64.71.184.190:53 out via fxp0 > Apr 18 13:12:04 pentarou last message repeated 5 times > > ...and our named syslog: > > Apr 18 13:11:33 pentarou named[77949]: ns_req: sendto([64.71.184.190].53): Permission denied > > So, it doesn't look like that's the offender. :-) > > By the way, something I didn't cover: 64.71.184.190 is our > secondary nameserver's WAN IP. It's private is 10.0.0.2. > > I'm still wondering why tcpdump isn't catching the I/O... That I can answer. The bpf(4) hooks lie very close to the "edges" of the stack, right in the device drivers. Outgoing packets that get blocked by the firewall never get low enough in the stack to get caught by BPF. I have a guess what those might be, but it'd be a weird feature. Perhaps the queries (potentially) involved with zone transfers use the transfer address? It'd be nice if you could get those outgoing packets. Can you turn on query logging within BIND? It _is_ possible to grab those packets before the firewall blocks them, but it might take some tricks with divert(4) sockets or other ugliness to do it. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 15:17:52 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0770537B401 for ; Fri, 18 Apr 2003 15:17:52 -0700 (PDT) Received: from web10402.mail.yahoo.com (web10402.mail.yahoo.com [216.136.130.94]) by mx1.FreeBSD.org (Postfix) with SMTP id 7C8E843FE1 for ; Fri, 18 Apr 2003 15:17:51 -0700 (PDT) (envelope-from opolyakov@yahoo.com) Message-ID: <20030418221751.69748.qmail@web10402.mail.yahoo.com> Received: from [67.112.212.200] by web10402.mail.yahoo.com via HTTP; Fri, 18 Apr 2003 15:17:51 PDT Date: Fri, 18 Apr 2003 15:17:51 -0700 (PDT) From: Oleg Polyakov To: freebsd-net@freebsd.org In-Reply-To: <20030418201645.GA77986@parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 22:17:52 -0000 --- Jeremy Chadwick wrote: > Oleg: > > I tried your recommendation of commenting out the transfer-source > line, and within a few moments of running this: > > ipfw zero 1005 && ndc stop && /usr/sbin/named -u bind -g bind > > ...saw the following in our security syslog: > > Apr 18 13:11:09 pentarou /kernel: ipfw: Entry 1005 cleared. > Apr 18 13:11:33 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 > 64.71.184.190:53 out via fxp0 > Apr 18 13:12:04 pentarou last message repeated 5 times > > ...and our named syslog: > > Apr 18 13:11:33 pentarou named[77949]: ns_req: sendto([64.71.184.190].53): > Permission denied > > So, it doesn't look like that's the offender. :-) > > By the way, something I didn't cover: 64.71.184.190 is our > secondary nameserver's WAN IP. It's private is 10.0.0.2. Possibly it's asymmetrical traffic. UDP query comes from that secondary through fxp1 and replay goes through fxp0 and got filtered out. Just run tcpdump -i fxp1 port 53 udp and check if there are anything unusual as packets from 64.71.184.190. > I'm still wondering why tcpdump isn't catching the I/O... I believe tcpdump catches everything after IPFW - you have to open firewall to check what those packets are... > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. | > > On Fri, Apr 18, 2003 at 01:09:36PM -0700, Oleg Polyakov wrote: > > You may want to comment out line: > > // transfer-source 10.0.0.1; > > > > Transfers to 10.0.0.0 should choose address 10.0.0.1 automagically. > > Transfers elsewhere should use zone-relevant transfer-source option. > > === message truncated === __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 15:22:12 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D69D337B401 for ; Fri, 18 Apr 2003 15:22:12 -0700 (PDT) Received: from vorbis.noc.easynet.net (vorbis.noc.easynet.net [195.40.1.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16BB443FAF for ; Fri, 18 Apr 2003 15:22:12 -0700 (PDT) (envelope-from chrisy@vorbis.noc.easynet.net) Received: from chrisy by vorbis.noc.easynet.net with local (Exim 4.10) id 196eFF-000AZo-00; Fri, 18 Apr 2003 23:22:09 +0100 Date: Fri, 18 Apr 2003 23:22:09 +0100 From: Chris Luke To: Brett Glass Message-ID: <20030418222209.GA39709@flix.net> Mail-Followup-To: Chris Luke , Brett Glass , Sten Daniel =?unknown-8bit?Q?S=F8rsdal?= , freebsd-net@freebsd.org References: <0AF1BBDF1218F14E9B4CCE414744E70F07DE93@exchange.wanglobal.net> <4.3.2.7.2.20030418111623.02819bd0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030418111623.02819bd0@localhost> User-Agent: Mutt/1.4i Organization: The Flirble Internet Exchange X-URL: http://www.flix.net/ X-FTP: ftp://ftp.flirble.org/ Sender: Chris Luke cc: freebsd-net@freebsd.org Subject: Re: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 22:22:13 -0000 Brett Glass wrote (on Apr 18): > Yes, but broadcast is needed for ARP. To tunnel effectively, > you need to be able to ARP (for example) the printer on the > LAN you're tunneling into. Tunnels are point-to-point connections. Each end of the link has an address, even if inherited from another interface, and these addresses are either known in advance, or exchanged or negotiated by a higher-level protocol, such as the negotiation stuff in PPP. Thus the address of the far end is known, and is entered as a route into the forwarding table. eg: chrisy@brae[~]> ifconfig ng1 ng1: flags=88d1 mtu 1500 inet 207.162.200.1 --> 207.162.200.2 netmask 0xffffffff The "-->" notation denotes a point-to-point interface where the address is known ahead of time. There's no need to map a layer2 address - there isn't one, in any case. The interface driver just sends the packets blindly down the line (virtual or not.) There's no MAC addresses involved, ergo no ARP, no need to broadcast. Generally, avoiding anything broadcast-like over any sort of wan-like interface is a good thing. Chris. -- == chrisy@flix.net From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 15:38:26 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6DDD37B401 for ; Fri, 18 Apr 2003 15:38:26 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 125D543FB1 for ; Fri, 18 Apr 2003 15:38:26 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org (12-234-159-107.client.attbi.com[12.234.159.107]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <2003041822382500200263bje>; Fri, 18 Apr 2003 22:38:25 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.8p1/8.12.3) with ESMTP id h3IMcOki040414; Fri, 18 Apr 2003 15:38:24 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.8p1/8.12.8/Submit) id h3IMcMi6040413; Fri, 18 Apr 2003 15:38:22 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Fri, 18 Apr 2003 15:38:22 -0700 From: "Crist J. Clark" To: Damian Gerow Message-ID: <20030418223822.GC39466@blossom.cjclark.org> References: <20030415223713.GB648@sentex.net> <00d001c303dc$191c2830$0b01a8c0@Beastie> <20030416190520.GJ648@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030416190520.GJ648@sentex.net> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: net@freebsd.org Subject: Re: [LONG] Re: IPSec tunnel setup problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 22:38:27 -0000 On Wed, Apr 16, 2003 at 03:05:20PM -0400, Damian Gerow wrote: > Thus spake Barry Irwin (bvi@itouchlabs.com) [16/04/03 01:52]: > > Can I suggest you try using TCPdump to see whats going on as well. > > I've done it. I see continual re-tries for Phase I, nothing for Phase II. > Here's what I see: > > tcpdump: > 14:31:33.613674 pyroxene.sentex.ca.isakmp > asylum.afflictions.org.isakmp: isakmp: phase 1 I agg: [|sa] > 14:31:53.428132 pyroxene.sentex.ca.isakmp > asylum.afflictions.org.isakmp: isakmp: phase 1 I agg: [|sa] Well, one weird thing is that pyroxene must be behind some kind of NAT device, > initiating: [snip] > 43:09.033625 64.7.134.90:500 -> 199.212.134.18:500: isakmp 1.0 msgid 00000000: phase 1 I agg: ^^^ > sa: doi=ipsec situation=identity > p: #1 protoid=isakmp transform=1 > t: #1 id=iketype=lifetype value=sectype=lifeduration value=0e10type=enc value=blowfishtype=keylen value=0080type=auth value=presharedtype=hash value=sha1type=group desc value=0005)))) > ke: key len=192) > nonce: n len=16) > id: idtype=IPv4 protoid=udp port=500 len=4 64.7.134.90) ^^^ > receiving: [snip] > 40:07.915101 64.7.134.90:41889 -> 199.212.134.18:500: isakmp 1.0 msgid 00000000: phase 1 I agg: ^^^^^ > (sa: doi=ipsec situation=identity > (p: #1 protoid=isakmp transform=1 > (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration value=0e10)(type=enc value=blowfish)(type=keylen value=0080)(type=auth value=preshared)(type=hash value=sha1)(type=group desc value=0005)))) > (ke: key len=192) > (nonce: n len=16) > (id: idtype=IPv4 protoid=udp port=500 len=4 64.7.134.90) ^^^ > 2003-04-16 14:40:07: DEBUG: remoteconf.c:134:getrmconf(): no remote configuration found. > 2003-04-16 14:40:07: ERROR: isakmp.c:851:isakmp_ph1begin_r(): couldn't find configuration. I'm not 100% as to whether that is a deal-breaker or not. This doesn't explain why initiating in the other direction doesn't work. But what kind of devices are in between these two hosts? What is doing NAT? -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 15:41:42 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBA8437B401 for ; Fri, 18 Apr 2003 15:41:42 -0700 (PDT) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F17A43FAF for ; Fri, 18 Apr 2003 15:41:42 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id QAA08153; Fri, 18 Apr 2003 16:41:24 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030418163428.02bf6480@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Apr 2003 16:41:19 -0600 To: Chris Luke From: Brett Glass In-Reply-To: <20030418222209.GA39709@flix.net> References: <4.3.2.7.2.20030418111623.02819bd0@localhost> <0AF1BBDF1218F14E9B4CCE414744E70F07DE93@exchange.wanglobal.net> <4.3.2.7.2.20030418111623.02819bd0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" cc: freebsd-net@freebsd.org Subject: Re: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 22:41:43 -0000 At 04:22 PM 4/18/2003, Chris Luke wrote: >Tunnels are point-to-point connections. Each end of the link >has an address, even if inherited from another interface, >and these addresses are either known in advance, or exchanged or >negotiated by a higher-level protocol, such as the negotiation >stuff in PPP. Thus the address of the far end is known, and is >entered as a route into the forwarding table. Even assuming that you don't need ARP (and SOMEONE has to do ARP if you're going to get to other addresses on the LAN you're tunneling into), there are many applications that do need to send out a broadcast. HP JetDirect and LapLink are two which I know these folks to be using. The broadcast address should be the correct one for the LAN into which you're tunneling, or these products won't work. --Brett From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 16:42:01 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C49D37B401 for ; Fri, 18 Apr 2003 16:42:01 -0700 (PDT) Received: from mail.parodius.com (mail.parodius.com [64.71.184.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id F008743F75 for ; Fri, 18 Apr 2003 16:42:00 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.9/8.12.9) with ESMTP id h3INfJjU086374 for ; Fri, 18 Apr 2003 16:41:19 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.9/8.12.9/Submit) id h3INfJTP086373 for freebsd-net@freebsd.org; Fri, 18 Apr 2003 16:41:19 -0700 (PDT) Date: Fri, 18 Apr 2003 16:41:19 -0700 From: Jeremy Chadwick To: freebsd-net@freebsd.org Message-ID: <20030418234119.GA85777@parodius.com> References: <20030418201645.GA77986@parodius.com> <1050703016.604363.667.nullmailer@cicuta.babolo.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1050703016.604363.667.nullmailer@cicuta.babolo.ru> User-Agent: Mutt/1.5.4i Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 23:42:01 -0000 Under what circumstances would the primary request data from the secondary on it's _public_ IP? My query-source directive is set to the public IP, and this IP should (according to BIND documentation) be used by both TCP and UDP queries (port #, however, cannot be guaranteed). I have no forwarders configured, and using topology makes no difference. The problem at hand does not seem to be zone transfer related, but I cannot verify this; I'm going off the fact that the transfer-source directives are working fine (both functionally and in the logs). Another user here on the list recommended I enable query logging (I hope it doesn't require a rebuild; this is stock 8.3.4 taken from src) -- I'll give that a shot and see if there's anything odd appearing there. I don't even understand on a technical level how BIND is able to send outgoing UDP packets from a src address that isn't even bound to the interface in question. I'm frustrated that there doesn't seem to be a workaround that I know of. Another administrator recommended using a "stub" zone, but I have no experience with such, and the DNS/BIND book does not cover them in very verbose detail... -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Sat, Apr 19, 2003 at 01:56:56AM +0400, .@babolo.ru wrote: > > > > By the way, something I didn't cover: 64.71.184.190 is our > > secondary nameserver's WAN IP. It's private is 10.0.0.2. > That can be the key - if secondary server > request your private master using public IP > > > I'm still wondering why tcpdump isn't catching the I/O... > Your ipfw rules forbid packets > before interface you are looking for. > Just ipfw forward them to another interface to catch them. From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 16:52:56 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E46D137B401 for ; Fri, 18 Apr 2003 16:52:55 -0700 (PDT) Received: from mail.parodius.com (mail.parodius.com [64.71.184.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DCB843F93 for ; Fri, 18 Apr 2003 16:52:55 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.9/8.12.9) with ESMTP id h3INqEjU086801 for ; Fri, 18 Apr 2003 16:52:14 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.9/8.12.9/Submit) id h3INqE2v086800 for freebsd-net@freebsd.org; Fri, 18 Apr 2003 16:52:14 -0700 (PDT) Date: Fri, 18 Apr 2003 16:52:14 -0700 From: Jeremy Chadwick To: freebsd-net@freebsd.org Message-ID: <20030418235214.GB85777@parodius.com> References: <20030418174956.GA71335@parodius.com> <20030418200936.82331.qmail@web10410.mail.yahoo.com> <20030418201645.GA77986@parodius.com> <20030418220229.GB39466@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030418220229.GB39466@blossom.cjclark.org> User-Agent: Mutt/1.5.4i Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 23:52:56 -0000 Since when? :-) That wouldn't make very much sense, and would be extremely misleading for network administrators. bpf should have the highest priority, well above ipfw. I just verified that fact with a test: blocking any telnet I/O across my public interface and telnetting in from my home workstation: $ ipfw add 350 deny tcp from any to any 23 via fxp0 00350 deny tcp from any to any 23 via fxp0 $ ipfw -a list 350 00350 0 0 deny tcp from any to any 23 via fxp0 $ tcpdump -p -ifxp0 -l -n "port 23" tcpdump: listening on fxp0 16:46:17.585420 12.234.135.66.43116 > 64.71.184.170.23: S 3333778257:3333778257(0) win 64240 (DF) 16:46:19.541515 12.234.135.66.43117 > 64.71.184.170.23: S 3333778257:3333778257(0) win 64240 (DF) 16:46:21.731619 12.234.135.66.43118 > 64.71.184.170.23: S 3333778257:3333778257(0) win 64240 (DF) $ ipfw -a list 350 00350 3 144 deny tcp from any to any 23 via fxp0 The fact that tcpdump does not see the erroneous behaviour BIND is exhibiting is very bothersome. What I have yet to do is run tcpdump on fxp1 and see if the traffic shows up there (and if it does, then I would classify this as a FreeBSD bug somewhere, while the origin itself would be a BIND bug). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Fri, Apr 18, 2003 at 03:02:29PM -0700, Crist J. Clark wrote: > On Fri, Apr 18, 2003 at 01:16:45PM -0700, Jeremy Chadwick wrote: > > Oleg: > > > > I tried your recommendation of commenting out the transfer-source > > line, and within a few moments of running this: > > > > ipfw zero 1005 && ndc stop && /usr/sbin/named -u bind -g bind > > > > ...saw the following in our security syslog: > > > > Apr 18 13:11:09 pentarou /kernel: ipfw: Entry 1005 cleared. > > Apr 18 13:11:33 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 64.71.184.190:53 out via fxp0 > > Apr 18 13:12:04 pentarou last message repeated 5 times > > > > ...and our named syslog: > > > > Apr 18 13:11:33 pentarou named[77949]: ns_req: sendto([64.71.184.190].53): Permission denied > > > > So, it doesn't look like that's the offender. :-) > > > > By the way, something I didn't cover: 64.71.184.190 is our > > secondary nameserver's WAN IP. It's private is 10.0.0.2. > > > > I'm still wondering why tcpdump isn't catching the I/O... > > That I can answer. The bpf(4) hooks lie very close to the "edges" of > the stack, right in the device drivers. Outgoing packets that get > blocked by the firewall never get low enough in the stack to get > caught by BPF. > > I have a guess what those might be, but it'd be a weird > feature. Perhaps the queries (potentially) involved with zone > transfers use the transfer address? > > It'd be nice if you could get those outgoing packets. Can you turn on > query logging within BIND? It _is_ possible to grab those packets > before the firewall blocks them, but it might take some tricks with > divert(4) sockets or other ugliness to do it. > -- > Crist J. Clark | cjclark@alum.mit.edu > | cjclark@jhu.edu > http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 19:27:48 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFAD537B401 for ; Fri, 18 Apr 2003 19:27:48 -0700 (PDT) Received: from web21201.mail.yahoo.com (web21201.mail.yahoo.com [216.136.129.59]) by mx1.FreeBSD.org (Postfix) with SMTP id A0ADD43FE0 for ; Fri, 18 Apr 2003 19:27:48 -0700 (PDT) (envelope-from marloncorleone@yahoo.com) Message-ID: <20030419022748.61044.qmail@web21201.mail.yahoo.com> Received: from [202.81.160.16] by web21201.mail.yahoo.com via HTTP; Fri, 18 Apr 2003 19:27:48 PDT Date: Fri, 18 Apr 2003 19:27:48 -0700 (PDT) From: marlon corleone To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: what entry to add in rc.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 02:27:49 -0000 what entry should i add in my rc.conf, to keep dc0 up? thanks __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 21:04:31 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5DB137B401 for ; Fri, 18 Apr 2003 21:04:30 -0700 (PDT) Received: from vorbis.noc.easynet.net (vorbis.noc.easynet.net [195.40.1.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E35843FE3 for ; Fri, 18 Apr 2003 21:04:30 -0700 (PDT) (envelope-from chrisy@vorbis.noc.easynet.net) Received: from chrisy by vorbis.noc.easynet.net with local (Exim 4.10) id 196jaU-000Dd9-00; Sat, 19 Apr 2003 05:04:26 +0100 Date: Sat, 19 Apr 2003 05:04:26 +0100 From: Chris Luke To: Brett Glass Message-ID: <20030419040426.GA36720@flirble.org> Mail-Followup-To: Chris Luke , Brett Glass , Chris Luke , Sten Daniel =?unknown-8bit?Q?S=F8rsdal?= , freebsd-net@freebsd.org References: <4.3.2.7.2.20030418111623.02819bd0@localhost> <0AF1BBDF1218F14E9B4CCE414744E70F07DE93@exchange.wanglobal.net> <4.3.2.7.2.20030418111623.02819bd0@localhost> <4.3.2.7.2.20030418163428.02bf6480@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030418163428.02bf6480@localhost> User-Agent: Mutt/1.4i Organization: The Flirble Organisation X-URL: http://www.flirble.org/ X-FTP: ftp://ftp.flirble.org/ Sender: Chris Luke cc: freebsd-net@freebsd.org cc: Chris Luke Subject: Re: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 04:04:31 -0000 Brett Glass wrote (on Apr 18): > Even assuming that you don't need ARP (and SOMEONE has to do > ARP if you're going to get to other addresses on the LAN you're > tunneling into), there are many applications that do need > to send out a broadcast. HP JetDirect and LapLink are two which > I know these folks to be using. The broadcast address should > be the correct one for the LAN into which you're tunneling, or > these products won't work. You only use ARP if there's an ethernet physically on your end, or some other layer 2 media that needs it (ATM LANE has an equivalent, for instance). If you have a /24 of a remote LAN (or whatever) via the tunnel, your machine needs no ARP to find out what it already knows - it already has a route and there's no media-specific addressing required. Tunnels generally have only two ends. This end and the other. Since you know which layer 3 addresses exist at this end, all others within any subnet masks at this end must exist at the other. Any data to the last adddress in the subnet (often known as the broadcast address) will either get dropped (as is the way with older IP implementations, or sometimes done deliberately if the source address is outside the subnet range, to avoid DoS attacks - "directed broadcast" in Cisco terms) or forwarded like traffic to any other address. The far end, however, if it has an ethernet, if configured to, will maintain an entry in its ARP table statically of the PPTP client address that it publishes (ie, responds to queries for) if it's in the same subnet as a lan it's connected to. No ARP on your, the PPTP client, end is required. If you're using IP addresses from a LAN at the far end, the far end does, however, need to proxy-arp those addresses. Whether Windows PPTP forwards addresses to the last address in a subnet, I don't know. It *should* treat it like any other address, and then the machine at the far end should then forward it, and the ethernet interface should then decide it's a broadcast address and forward it to the hard-coded ethernet broadcast address. However, I wouldn't bet on it. If the Windows PPTP client appears to be classfull, then it likely treats the first address (network address) and the last address (broadcast) in any given subnet as special and may do special things with them. YMMV. It was CIDRisaition that removed this special treatment, though in general the world was/is slow to actually adopt this particular facet of the previously mentioned RFCs. As for software that relies on the broadcast domain, there are generally better ways (at least I think so) of organising the network that work better in the long run. Running your jetdirects via a printer queue on some machine - windows or otherwise - is the most obvious, for instance. Chris. -- == chrisy@flirble.org From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 21:30:57 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75DF237B401 for ; Fri, 18 Apr 2003 21:30:57 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DB8843FE9 for ; Fri, 18 Apr 2003 21:30:56 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9/8.12.9) with ESMTP id h3J4UtVi031606; Sat, 19 Apr 2003 00:30:55 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9/8.12.9/Submit) id h3J4Ut5f031605; Sat, 19 Apr 2003 00:30:55 -0400 (EDT) Date: Sat, 19 Apr 2003 00:30:55 -0400 From: Barney Wolff To: Jeremy Chadwick Message-ID: <20030419043055.GA31406@pit.databus.com> References: <20030418174956.GA71335@parodius.com> <20030418200936.82331.qmail@web10410.mail.yahoo.com> <20030418201645.GA77986@parodius.com> <20030418220229.GB39466@blossom.cjclark.org> <20030418235214.GB85777@parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030418235214.GB85777@parodius.com> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) cc: freebsd-net@freebsd.org Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 04:30:57 -0000 On Fri, Apr 18, 2003 at 04:52:14PM -0700, Jeremy Chadwick wrote: > Since when? :-) That wouldn't make very much sense, and > would be extremely misleading for network administrators. > bpf should have the highest priority, well above ipfw. > > I just verified that fact with a test: blocking any telnet I/O > across my public interface and telnetting in from my home > workstation: You didn't listen to the answer: bpf is closer to the driver than ipfw, so it will see inbound packets that ipfw will block, but not see outbound packets that ipfw has already blocked. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 21:34:49 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D975137B401 for ; Fri, 18 Apr 2003 21:34:49 -0700 (PDT) Received: from mail.parodius.com (mail.parodius.com [64.71.184.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1B3F43F3F for ; Fri, 18 Apr 2003 21:34:47 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.9/8.12.9) with ESMTP id h3J4Y4jU007088 for ; Fri, 18 Apr 2003 21:34:05 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.9/8.12.9/Submit) id h3J4Y4Rt007087 for freebsd-net@freebsd.org; Fri, 18 Apr 2003 21:34:04 -0700 (PDT) Date: Fri, 18 Apr 2003 21:34:04 -0700 From: Jeremy Chadwick To: freebsd-net@freebsd.org Message-ID: <20030419043404.GA7069@parodius.com> References: <20030418174956.GA71335@parodius.com> <20030418200936.82331.qmail@web10410.mail.yahoo.com> <20030418201645.GA77986@parodius.com> <20030418220229.GB39466@blossom.cjclark.org> <20030418235214.GB85777@parodius.com> <20030419043055.GA31406@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030419043055.GA31406@pit.databus.com> User-Agent: Mutt/1.5.4i Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 04:34:50 -0000 Ah, you're right -- I definitely skipped over the "outgoing" phrase in Crist's note. My apologies. I'll try taking a look at the interface without the outgoing ipfw blocks in place, and report back. I'm starting to wonder if it's NOTIFY traffic... -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Sat, Apr 19, 2003 at 12:30:55AM -0400, Barney Wolff wrote: > On Fri, Apr 18, 2003 at 04:52:14PM -0700, Jeremy Chadwick wrote: > > Since when? :-) That wouldn't make very much sense, and > > would be extremely misleading for network administrators. > > bpf should have the highest priority, well above ipfw. > > > > I just verified that fact with a test: blocking any telnet I/O > > across my public interface and telnetting in from my home > > workstation: > > You didn't listen to the answer: bpf is closer to the driver than ipfw, > so it will see inbound packets that ipfw will block, but not see outbound > packets that ipfw has already blocked. > > -- > Barney Wolff http://www.databus.com/bwresume.pdf > I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 22:08:31 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABED937B401 for ; Fri, 18 Apr 2003 22:08:31 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id D692543FBF for ; Fri, 18 Apr 2003 22:08:30 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D365915210; Sat, 19 Apr 2003 14:09:43 +0900 (JST) Date: Sat, 19 Apr 2003 14:08:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jeremy Chadwick In-Reply-To: <20030418234119.GA85777@parodius.com> References: <20030418201645.GA77986@parodius.com> <1050703016.604363.667.nullmailer@cicuta.babolo.ru> <20030418234119.GA85777@parodius.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 26 cc: freebsd-net@freebsd.org Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 05:08:32 -0000 >>>>> On Fri, 18 Apr 2003 16:41:19 -0700, >>>>> Jeremy Chadwick said: > Under what circumstances would the primary request data from > the secondary on it's _public_ IP? My query-source directive > is set to the public IP, and this IP should (according to BIND > documentation) be used by both TCP and UDP queries (port #, > however, cannot be guaranteed). You seemed to misunderstand the comment. It said "the problematic situation can happen when ***the secondary sends a query from its public address to the primary's private address***": query secondary:----------------->primary 64.71.184.190 10.0.0.1 (rejected)<---- response So I guess you should look at the configuration in secondary, not primary. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 23:48:45 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A881937B401 for ; Fri, 18 Apr 2003 23:48:45 -0700 (PDT) Received: from mail.parodius.com (mail.parodius.com [64.71.184.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1468343FE3 for ; Fri, 18 Apr 2003 23:48:45 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.9/8.12.9) with ESMTP id h3J6m1jU012021 for ; Fri, 18 Apr 2003 23:48:01 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.9/8.12.9/Submit) id h3J6m19X012020 for freebsd-net@freebsd.org; Fri, 18 Apr 2003 23:48:01 -0700 (PDT) Date: Fri, 18 Apr 2003 23:48:01 -0700 From: Jeremy Chadwick To: freebsd-net@freebsd.org Message-ID: <20030419064801.GA11635@parodius.com> References: <20030418201645.GA77986@parodius.com> <1050703016.604363.667.nullmailer@cicuta.babolo.ru> <20030418234119.GA85777@parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 06:48:46 -0000 The secondary is configured literally identical to the primary, except that the IPs have changed and _all_ of the zones are type slave. I see the exact same problem on the secondary (again, outgoing traffic on the public interface with an IP of the private), except that the src & dst IPs apply to the private IP on the secondary and the WAN IP of the primary, respectively. Sorry if that's confusing. :-) Thank you for your below example -- I didn't consider that BIND would do something that ""silly"" (note quotes), but now it makes sense. I believe removing the query-source option could in fact solve the problem, but there is a specific reason for it's existance -- we rely on the MAPS RBL+ service for SBL lookups, which are DNS based. Permission to the RBL+ service is based on the IP doing the query. Since the nameserver IPs are IP aliases, if I do not specify this, the queries come from the first IP in the list shown in ifconfig -a. If there's a workaround for this, I'd love to hear it. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Sat, Apr 19, 2003 at 02:08:19PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Fri, 18 Apr 2003 16:41:19 -0700, > >>>>> Jeremy Chadwick said: > > > Under what circumstances would the primary request data from > > the secondary on it's _public_ IP? My query-source directive > > is set to the public IP, and this IP should (according to BIND > > documentation) be used by both TCP and UDP queries (port #, > > however, cannot be guaranteed). > > You seemed to misunderstand the comment. It said "the problematic > situation can happen when ***the secondary sends a query from its > public address to the primary's private address***": > > query > secondary:----------------->primary > 64.71.184.190 10.0.0.1 > (rejected)<---- > response > > So I guess you should look at the configuration in secondary, not > primary. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Sat Apr 19 07:53:26 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E57B937B401; Sat, 19 Apr 2003 07:53:26 -0700 (PDT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2748443FB1; Sat, 19 Apr 2003 07:53:26 -0700 (PDT) (envelope-from vjardin@wanadoo.fr) Received: from mercure.vincentjardin.net (rennes-1-a7-62-147-212-239.dial.proxad.net [62.147.212.239]) by postfix4-1.free.fr (Postfix) with ESMTP id 82D5C19EC4; Sat, 19 Apr 2003 16:53:23 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: Vincent Jardin To: freebsd-net@freebsd.org, freebsd-atm@freebsd.org Date: Sat, 19 Apr 2003 16:53:18 +0200 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200304191653.18655.vjardin@wanadoo.fr> Subject: Netgraph ISR conflict with HARP ISR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 14:53:27 -0000 Hi, My kernel is compiled with the HARP stack (ie ATM) support. When I load t= he=20 Netgraph module, the HARP stack is not able anymore to process the incomi= ng=20 packets. It is due to the HARP's netisrs entry that is replaced by the Netgraph's = ISR=20 one !!!. For example, see on the enclosed log, netisrs[AF_ATM] is pointed= on=20 ngintr. In fact, it looks like there is a wrong comment within the source code ab= out=20 AF_NETGRAPH and NETISR_NETGRAPH, $ grep AF_NETGRAPH */*h =20 net/netisr.h:#define NETISR_NETGRAPH 30 /* same as AF_NET= GRAPH=20 */ sys/socket.h:#define AF_NETGRAPH 32 /* Netgraph socke= ts */ sys/socket.h:#define PF_NETGRAPH AF_NETGRAPH It means that NETISR_NETGRAPH is not AF_NETGRAPH. In fact it would be=20 impossible because netisrs can contain only 32 entry.=20 netisrs[NETISR_NETGRAPH] would be the 33th one ! whereas netatm/atm_if.h:#define NETISR_ATM AF_ATM sys/socket.h:#define AF_ATM 30 /* ATM */ That's ok, but Netgraph has stolen the ATM ISR entry ;-( What could be the clean solution ? Vincent PS: I get this issue on FreeBSD 4.7: # gdb -k kernel.debug (kgdb) add-symbol-file netgraph.ko 0xc11ee000+0x2a64 add symbol table from file "netgraph.ko" at text_addr =3D 0xc11f0a64? (y or n) y Reading symbols from netgraph.ko...done. (kgdb) p ngintr $5 =3D {void ()} 0xc11f26b8 (kgdb) p atm_intr $6 =3D {void ()} 0xc01d35bc (kgdb) netisrs[AF_ATM] 0xc11f26b8 ie ngintr !! From owner-freebsd-net@FreeBSD.ORG Sat Apr 19 09:04:04 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0E4037B401 for ; Sat, 19 Apr 2003 09:04:04 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 785D743FE9 for ; Sat, 19 Apr 2003 09:04:03 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BF42315210; Sun, 20 Apr 2003 01:05:17 +0900 (JST) Date: Sun, 20 Apr 2003 01:03:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jeremy Chadwick In-Reply-To: <20030419064801.GA11635@parodius.com> References: <20030418201645.GA77986@parodius.com> <1050703016.604363.667.nullmailer@cicuta.babolo.ru> <20030418234119.GA85777@parodius.com> <20030419064801.GA11635@parodius.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 39 cc: freebsd-net@freebsd.org Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 16:04:05 -0000 >>>>> On Fri, 18 Apr 2003 23:48:01 -0700, >>>>> Jeremy Chadwick said: > The secondary is configured literally identical to the > primary, except that the IPs have changed and _all_ of > the zones are type slave. > I see the exact same problem on the secondary (again, > outgoing traffic on the public interface with an IP of > the private), except that the src & dst IPs apply to > the private IP on the secondary and the WAN IP of the > primary, respectively. Sorry if that's confusing. :-) > I believe removing the query-source option could in fact > solve the problem, but there is a specific reason for it's > existance -- we rely on the MAPS RBL+ service for SBL lookups, > which are DNS based. Permission to the RBL+ service is based > on the IP doing the query. Since the nameserver IPs are > IP aliases, if I do not specify this, the queries come from > the first IP in the list shown in ifconfig -a. > If there's a workaround for this, I'd love to hear it. :-) I guess the query from the client that caused the problem was the SOA check before zone transfer. If this is correct, you can control the source address of such queries with BIND 9's transfer-source. So, please try: 1. install BIND 9 at the secondary server. 2. add the following in the zone statement for which the secondary serves: transfer-source 10.0.0.2; I don't know the reason for the error at the secondary side. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Sat Apr 19 12:43:28 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB9A837B401 for ; Sat, 19 Apr 2003 12:43:28 -0700 (PDT) Received: from mail.parodius.com (mail.parodius.com [64.71.184.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13FC543FBF for ; Sat, 19 Apr 2003 12:43:28 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.9/8.12.9) with ESMTP id h3JJgejU044215 for ; Sat, 19 Apr 2003 12:42:40 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.9/8.12.9/Submit) id h3JJge0n044214 for freebsd-net@freebsd.org; Sat, 19 Apr 2003 12:42:40 -0700 (PDT) Date: Sat, 19 Apr 2003 12:42:40 -0700 From: Jeremy Chadwick To: freebsd-net@freebsd.org Message-ID: <20030419194240.GA43491@parodius.com> References: <20030418201645.GA77986@parodius.com> <1050703016.604363.667.nullmailer@cicuta.babolo.ru> <20030418234119.GA85777@parodius.com> <20030419064801.GA11635@parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 19:43:29 -0000 It definitely looks to be an SOA check. After removing the outbound ipfw block and running tcpdump, I'm now able to see what's going on. Here's a tcpdump snippet taken from the _primary_ nameserver: 01:59:20.784249 10.0.0.1.53 > 64.71.184.190.53: 29820* 1/2/3 SOA (247) 0x0000 4500 0113 19e8 0000 4011 5cec 0a00 0001 E.......@.\..... 0x0010 4047 b8be 0035 0035 00ff c48a 747c 8480 @G...5.5....t|.. 0x0020 0001 0001 0002 0003 0b64 656c 7461 706c .........deltapl 0x0030 6179 6572 0363 6f6d 0000 0600 01c0 0c00 ayer.com........ 0x0040 0600 0100 0007 0800 3003 6e73 3108 7061 ........0.ns1.pa 0x0050 726f 6469 7573 c018 0a68 6f73 746d 6173 rodius...hostmas 0x0060 7465 72c0 310b eef3 1400 002a 3000 000e ter.1......*0... 0x0070 1000 093a 8000 0007 08c0 0c00 0200 0100 ...:............ 0x0080 0007 0800 02c0 2dc0 0c00 0200 0100 0007 ......-......... 0x0090 0800 0603 4e53 32c0 31c0 2d00 0100 0100 ....NS2.1.-..... 0x00a0 000e 1000 0440 47b8 abc0 7700 0100 0100 .....@G...w..... 0x00b0 000e 1000 0440 47b8 be14 7065 6e74 6172 .....@G...pentar 0x00c0 6f75 2d67 6162 7269 656c 2d4c 414e 0000 ou-gabriel-LAN.. 0x00d0 fa00 ff00 0000 0000 3a08 484d 4143 2d4d ........:.HMAC-M 0x00e0 4435 0753 4947 2d41 4c47 0352 4547 0349 D5.SIG-ALG.REG.I 0x00f0 4e54 0000 003e a10f e801 2c00 10c0 5689 NT...>....,...V. 0x0100 472e 2631 2b54 099b 80f5 4063 0c74 7c00 G.&1+T....@c.t|. 0x0110 0000 00 ... It's definitely an SOA lookup, and the dst IP is the secondary NS in the zone itself (as Len's Email confirms). The problem, in a strange way, looks to be of the chicken-and-egg sort. What I wanted to accomplish was the following: 1. Perform zone transfers between primary/secondary entirely across a private network interface (fxp1), as well as notifies (for zone updates, etc.). 2. Perform lookup queries based upon the network interface that seems "most logical" (i.e. 10.0.0.0/8 --> 10.0.0.1 --> fxp1, etc.) 3. Keep NS records in the zones in question as assigned to public IPs, as changing the NS IPs to point to 10.0.0.0/8 would make the zone data inaccessible in the real world. The zones are public zones, and aren't private zones. 4. Execute external lookups (due to MAPS RBL+) from a specific public IP bound to the box itself. I should note that I have tried BIND-9 on the secondary (and not the primary), using transfer-source (I use this on BIND-8 per zone as well) and notify-source, and it did not seem to make any difference. I still saw the same behaviour above, except on an even larger scale. I believe Len's comments explain this. It honestly sounds like I should move back to doing transfers, notifies, and queries all across the public IPs which would eliminate the use of the private network for distribution. The two nameservers are connected on the same switch. Thanks for the help, everyone. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Sun, Apr 20, 2003 at 01:03:53AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Fri, 18 Apr 2003 23:48:01 -0700, > >>>>> Jeremy Chadwick said: > > > The secondary is configured literally identical to the > > primary, except that the IPs have changed and _all_ of > > the zones are type slave. > > > I see the exact same problem on the secondary (again, > > outgoing traffic on the public interface with an IP of > > the private), except that the src & dst IPs apply to > > the private IP on the secondary and the WAN IP of the > > primary, respectively. Sorry if that's confusing. :-) > > > I believe removing the query-source option could in fact > > solve the problem, but there is a specific reason for it's > > existance -- we rely on the MAPS RBL+ service for SBL lookups, > > which are DNS based. Permission to the RBL+ service is based > > on the IP doing the query. Since the nameserver IPs are > > IP aliases, if I do not specify this, the queries come from > > the first IP in the list shown in ifconfig -a. > > > If there's a workaround for this, I'd love to hear it. :-) > > I guess the query from the client that caused the problem was the SOA > check before zone transfer. If this is correct, you can control the > source address of such queries with BIND 9's transfer-source. So, > please try: > > 1. install BIND 9 at the secondary server. > 2. add the following in the zone statement for which the secondary > serves: > transfer-source 10.0.0.2; > > I don't know the reason for the error at the secondary side. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Sat Apr 19 13:40:06 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B09137B401 for ; Sat, 19 Apr 2003 13:40:06 -0700 (PDT) Received: from mail.parodius.com (mail.parodius.com [64.71.184.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBB1443FB1 for ; Sat, 19 Apr 2003 13:40:05 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.9/8.12.9) with ESMTP id h3JKdHjU046348 for ; Sat, 19 Apr 2003 13:39:17 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.9/8.12.9/Submit) id h3JKdHE3046347 for freebsd-net@freebsd.org; Sat, 19 Apr 2003 13:39:17 -0700 (PDT) Date: Sat, 19 Apr 2003 13:39:17 -0700 From: Jeremy Chadwick To: freebsd-net@freebsd.org Message-ID: <20030419203917.GA46312@parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: Fwd: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 20:40:06 -0000 A bit hasty -- I didn't realise Len's comment was sent to me personally. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | ----- Forwarded message from Len Conrad ----- > Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) > by mail.parodius.com (8.12.9/8.12.9) with ESMTP id h3JGH3jU036342 > for ; Sat, 19 Apr 2003 09:17:05 -0700 (PDT) > (envelope-from LConrad@Go2France.com) > Received: from VirusGate.MEIway.com (virus-gate.meiway.com [212.73.210.91]) > by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id 2BA4FEF42D > for ; Sat, 19 Apr 2003 18:14:51 +0200 (CEST) > Received: from localhost (localhost.meiway.com [127.0.0.1]) > by VirusGate.MEIway.com (Postfix) with SMTP id 348F65D009 > for ; Sat, 19 Apr 2003 18:18:19 +0200 (CEST) > Received: from mail.Go2France.com (ms1.meiway.com [212.73.210.73]) > by VirusGate.MEIway.com (Postfix) with ESMTP id 80EF85D008 > for ; Sat, 19 Apr 2003 18:18:18 +0200 (CEST) > Received: from tx0-go2france-c.Go2France.com [24.242.169.51] by mail.Go2France.com with ESMTP > (SMTPD32-6.06) id AB7AA86900A8; Sat, 19 Apr 2003 18:38:18 +0200 > Message-Id: <5.2.0.9.0.20030419111509.0270d818@mail.go2france.com> > X-Sender: LConrad@Go2France.com@mail.go2france.com > X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 > Date: Sat, 19 Apr 2003 11:17:38 -0500 > To: Jeremy Chadwick > From: Len Conrad > Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? > In-Reply-To: <20030418234119.GA85777@parodius.com> > References: <1050703016.604363.667.nullmailer@cicuta.babolo.ru> > <20030418201645.GA77986@parodius.com> > <1050703016.604363.667.nullmailer@cicuta.babolo.ru> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii"; format=flowed > Status: RO > X-Status: A > Content-Length: 410 > Lines: 12 > > > > Under what circumstances would the primary request data from > > the secondary on it's _public_ IP? > > NOTIFY "queries" from master to slave go to the IP of zone NS records > > Len > > > _____________________________________________________________________ > http://MenAndMice.com/DNS-training: San Jose; Denver; New York; Seattle > IMGate.MEIway.com: anti-spam gateway, effective on 1000's of sites, free > ----- End forwarded message ----- From owner-freebsd-net@FreeBSD.ORG Sat Apr 19 15:21:44 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 383D837B404 for ; Sat, 19 Apr 2003 15:21:44 -0700 (PDT) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62FF243FAF for ; Sat, 19 Apr 2003 15:21:42 -0700 (PDT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 61971 invoked from network); 19 Apr 2003 22:39:22 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 19 Apr 2003 22:39:22 -0000 Received: (nullmailer pid 720 invoked by uid 136); Sat, 19 Apr 2003 22:24:39 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20030419064801.GA11635@parodius.com> To: Jeremy Chadwick Date: Sun, 20 Apr 2003 02:24:38 +0400 (MSD) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1050791079.007237.719.nullmailer@cicuta.babolo.ru> cc: freebsd-net@freebsd.org Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 22:21:44 -0000 > The secondary is configured literally identical to the > primary, except that the IPs have changed and _all_ of > the zones are type slave. > > I see the exact same problem on the secondary (again, > outgoing traffic on the public interface with an IP of > the private), except that the src & dst IPs apply to > the private IP on the secondary and the WAN IP of the > primary, respectively. Sorry if that's confusing. :-) > > Thank you for your below example -- I didn't consider that > BIND would do something that ""silly"" (note quotes), but > now it makes sense. > > I believe removing the query-source option could in fact > solve the problem, but there is a specific reason for it's > existance -- we rely on the MAPS RBL+ service for SBL lookups, > which are DNS based. Permission to the RBL+ service is based > on the IP doing the query. Since the nameserver IPs are > IP aliases, if I do not specify this, the queries come from > the first IP in the list shown in ifconfig -a. > > If there's a workaround for this, I'd love to hear it. :-) I use different named in different jails for public and private zones. Each pair on one host. Jail garantee that only dedicated IP will be used. possible transfers are: host1 host2 priv named <---> priv named ^ ^ | | V V pub named <----> pub named public named knows nothing about private zones private named is used by clients and forwards queryes to his public partner on the same host for non-private zones and have all private zones as master or slave PS http://free.babolo.ru/ports/jailup/ to easy establish jailed services From owner-freebsd-net@FreeBSD.ORG Sat Apr 19 15:27:10 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F35A237B401 for ; Sat, 19 Apr 2003 15:27:09 -0700 (PDT) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE9C043FDD for ; Sat, 19 Apr 2003 15:27:07 -0700 (PDT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 69705 invoked from network); 19 Apr 2003 22:44:49 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 19 Apr 2003 22:44:49 -0000 Received: (nullmailer pid 740 invoked by uid 136); Sat, 19 Apr 2003 22:30:06 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20030419203917.GA46312@parodius.com> To: Jeremy Chadwick Date: Sun, 20 Apr 2003 02:30:06 +0400 (MSD) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1050791406.354360.739.nullmailer@cicuta.babolo.ru> cc: freebsd-net@freebsd.org Subject: Re: Fwd: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 22:27:10 -0000 > A bit hasty -- I didn't realise Len's comment was sent to > me personally. > > > Under what circumstances would the primary request data from > > > the secondary on it's _public_ IP? > > > > NOTIFY "queries" from master to slave go to the IP of zone NS records If zone has @ NS some.server @ NS another.server then after reload of this zone NOTIFY is sent to some.server and another.server From owner-freebsd-net@FreeBSD.ORG Sat Apr 19 15:40:02 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7800837B401 for ; Sat, 19 Apr 2003 15:40:02 -0700 (PDT) Received: from mail.parodius.com (mail.parodius.com [64.71.184.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id D987D43F75 for ; Sat, 19 Apr 2003 15:40:01 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.9/8.12.9) with ESMTP id h3JMdDjU051090 for ; Sat, 19 Apr 2003 15:39:13 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.9/8.12.9/Submit) id h3JMdD8S051089 for freebsd-net@freebsd.org; Sat, 19 Apr 2003 15:39:13 -0700 (PDT) Date: Sat, 19 Apr 2003 15:39:13 -0700 From: Jeremy Chadwick To: freebsd-net@freebsd.org Message-ID: <20030419223913.GA51072@parodius.com> References: <20030419064801.GA11635@parodius.com> <1050791079.007237.719.nullmailer@cicuta.babolo.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1050791079.007237.719.nullmailer@cicuta.babolo.ru> User-Agent: Mutt/1.5.4i Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 22:40:02 -0000 I hadn't considered jails -- I can't believe I forgot about them. An excellent idea. For now, I've moved both of my nameservers over to relying entirely on the public IP network for transmission of everything, and as expected, it works great. I might have to try the jail method for the private network! Thanks. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Sun, Apr 20, 2003 at 02:24:38AM +0400, "."@babolo.ru wrote: > > The secondary is configured literally identical to the > > primary, except that the IPs have changed and _all_ of > > the zones are type slave. > > > > I see the exact same problem on the secondary (again, > > outgoing traffic on the public interface with an IP of > > the private), except that the src & dst IPs apply to > > the private IP on the secondary and the WAN IP of the > > primary, respectively. Sorry if that's confusing. :-) > > > > Thank you for your below example -- I didn't consider that > > BIND would do something that ""silly"" (note quotes), but > > now it makes sense. > > > > I believe removing the query-source option could in fact > > solve the problem, but there is a specific reason for it's > > existance -- we rely on the MAPS RBL+ service for SBL lookups, > > which are DNS based. Permission to the RBL+ service is based > > on the IP doing the query. Since the nameserver IPs are > > IP aliases, if I do not specify this, the queries come from > > the first IP in the list shown in ifconfig -a. > > > > If there's a workaround for this, I'd love to hear it. :-) > I use different named in different jails for > public and private zones. > Each pair on one host. > Jail garantee that only dedicated IP will be used. > > possible transfers are: > > host1 host2 > > priv named <---> priv named > ^ ^ > | | > V V > pub named <----> pub named > > public named knows nothing about private zones > private named is used by clients and > forwards queryes to his public partner > on the same host for non-private zones > and have all private zones as master or slave > > PS > http://free.babolo.ru/ports/jailup/ > to easy establish jailed services > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"