gif tunnel timeout problems
I have noticed, that over a certain period of time, if there is no packets going trough tunnel, other side of tunnel becomes unreachable. I must ping or made a connection to physical address to reestablish connection or ping tunneling IP class on other side and wait for 10 -15 seconds to reestablish tunnel. Strange. I have that problem in 4.3 release cvsupped before month ago and the problem persists in newer versions ( when gif has been modified ). Many thanks, Cuk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: gif tunnel timeout problems
Marko, Marko Cuk wrote: > > I have noticed, that over a certain period of time, if there is no packets going >trough tunnel, other side of tunnel becomes unreachable. Could you show us your network configuration of both sides? Also, how long time does it take from when you have succeeded to communicate with the other tunnel end to when you see the problem? > I must ping or made a connection to physical address to reestablish connection or >ping tunneling IP class on other side and wait for 10 -15 seconds to reestablish >tunnel. > > Strange. I have that problem in 4.3 release cvsupped before month ago and the >problem persists in newer versions ( when gif has been modified ). The routing table information, arp/ndp table information of BEFORE the problem and AFTER the problem may help. Please capture these information using netstat -nr, arp -na, ndp -na and show us too. --- Keiichi SHIMA <[EMAIL PROTECTED]> Internet Initiative Japan Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: What is 'checksum offload'?
Alfred Perlstein <[EMAIL PROTECTED]> writes: > * Alex Kapranoff <[EMAIL PROTECTED]> [010817 01:24] wrote: ... >> Oh, and what's a jumbogram? > > Large frames, larger than standard ethernet MTU, afaik they're > 8 or 9k. I thought it was an IPv6 packet with payload >= 2^16 bytes. rfc2675 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: What is 'checksum offload'?
> > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > > * Alex Kapranoff <[EMAIL PROTECTED]> [010817 01:24] wrote: > ... > >> Oh, and what's a jumbogram? > > > > Large frames, larger than standard ethernet MTU, afaik they're > > 8 or 9k. > > I thought it was an IPv6 packet with payload >= 2^16 bytes. > rfc2675 "Jumbo Frames" are (gigabit) ethernet data frames holding up to 9 Kbytes. I am certain "jumbogram" is referring to the same thing. -- Wes Peters To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: What is 'checksum offload'?
> > I'm in the process of translation release notes and have trouble > > understanding and thus interpreting the term 'checksum offload' which is > > a feature of nge(4) and lge(4) drivers. Does it mean that the > > controllers are able to compute TCP/IP checksums in hardware thus taking > > off load from CPU? Don't hesitate to tell me I'm stupid and this has > > nothing to do with TCP/IP :) > > Yes, that's the point of checksum offloading. Is there a FastEthernet card that has this feature? I'm not sure if it'd be all that useful since the throughput isn't as high as in gigabit ethernet but perhaps it has its uses in a CPU limited device. Just curious. -- Giovanni Pohl's law: Nothing is so good that somebody, somewhere, will not hate it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: What is 'checksum offload'?
On Fri, Aug 17, 2001 at 06:22:19PM -0300, Giovanni Picoli Tirloni wrote: > > Is there a FastEthernet card that has this feature? I'm not sure if > it'd be all that useful since the throughput isn't as high as in > gigabit ethernet but perhaps it has its uses in a CPU limited device. > Just curious. Yes. The cards supported by the txp driver support checksum offloading, however, the driver currently supports it on recieve only. -- 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 PGP signature
IPSec VPN tunnel question
I am trying to setup an IPSec based VPN between my FreeBSD server, which is running IPFW w/ a custom ruleset and NATD for my home network, and a Netopia R9100 Dual Ethernet router. I am attempting to use IPSec/tunnel/esp/hmac-md5 authentication/no encryption. Below is my configuration: Output from 'uname -a': FreeBSD firewall.crimsonwasteland.com 4.4-PRERELEASE FreeBSD 4.4-PRERELEASE #0: Sat Aug 11 09:30:22 GMT 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FIREWALL i386 Public IP on xl0: 24.181.119.107 Private IP on xl1: 172.16.69.1 Public IP on Netopia: x.x.x.x Private IP on Netopia: 172.16.250.1 Snippet of IPFW Ruleset: 00010 allow ip from any to x.x.x.x out xmit gif0 00020 allow ip from x.x.x.x to any in recv gif0 00030 allow ip from any to 172.16.250.0/24 out xmit gif0 00040 allow ip from 172.16.250.0/24 to any in recv gif0 00050 divert 8668 ip from any to any via xl0 00100 allow ip from any to any via lo0 00200 deny log ip from any to 127.0.0.0/8 00300 deny log ip from 127.0.0.0/8 to any ... Several rules allowing specific services ... 65500 deny log ip from any to any Output from ifconfig gif0: gif0: flags=8051 mtu 1280 tunnel inet 24.181.119.107 --> x.x.x.x inet 172.16.69.1 --> 172.16.250.1 netmask 0xff00 inet6 fe80::204:76ff:fe6f:7136%gif0 prefixlen 64 scopeid 0x8 Output from setkey -D: x.x.x.x 24.181.119.107 esp mode=tunnel spi=2568731067(0x991bb9bb) reqid=0(0x) E: null A: hmac-md5 75b916ac 534cef32 d3db8a44 cf5b62c1 replay=0 flags=0x0040 state=mature seq=1 pid=23835 created: Aug 17 20:53:11 2001 current: Aug 17 20:53:14 2001 diff: 3(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0hard: 0 soft: 0 refcnt=1 24.181.119.107 x.x.x.x esp mode=tunnel spi=2568731067(0x991bb9bb) reqid=0(0x) E: null A: hmac-md5 75b916ac 534cef32 d3db8a44 cf5b62c1 replay=0 flags=0x0040 state=mature seq=0 pid=23835 created: Aug 17 20:53:11 2001 current: Aug 17 20:53:14 2001 diff: 3(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0hard: 0 soft: 0 refcnt=1 Output from setkey -DP: 172.16.250.0/24[any] 172.16.69.0/24[any] any in ipsec esp/tunnel/x.x.x.x-24.181.119.107/require spid=10 seq=1 pid=23842 refcnt=1 172.16.69.0/24[any] 172.16.250.0/24[any] any out ipsec esp/tunnel/24.181.119.107-x.x.x.x/require spid=9 seq=0 pid=23842 refcnt=1 Output from netstat -nr: Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default24.181.118.1 UGSc 30 234144xl0 24.181.118/23 link#1 UC 20xl0 24.181.118.1 0:50:b:7:44:1c UHLW 280xl0 1199 24.181.119.107 0:4:76:6f:71:36UHLW02lo0 127.0.0.1 127.0.0.1 UH 00lo0 172.16.69/24 link#2 UC 40xl1 172.16.69.10:4:76:6f:71:4eUHLW1 8107lo0 172.16.69.20:10:4b:33:79:b9 UHLW6 752816xl1 1198 172.16.69.254 link#2 UHLW1 9836xl1 172.16.69.255 ff:ff:ff:ff:ff:ff UHLWb 2 1523xl1 172.16.250.1 172.16.69.1UH 0 25 gif0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%xl0/64 link#1UC xl0 fe80::204:76ff:fe6f:7136%xl0 0:4:76:6f:71:36 UHL lo0 fe80::%xl1/64 link#2UC xl1 fe80::204:76ff:fe6f:714e%xl1 0:4:76:6f:71:4e UHL lo0 fe80::%lo0/64 fe80::1%lo0 Uc lo0 fe80::1%lo0 link#4UHL lo0 fe80::%gif0/64link#8UC gif0 fe80::204:76ff:fe6f:7136%gif0 link#8UHL lo0 ff01::/32 ::1 U lo0 ff02::%xl0/32 link#1UC xl0 ff02::%xl1/32 link#2UC xl1 ff02::%lo0/32 ::1 UC lo0 ff02::%gif0/32link#8UC gif0 Snippet from dmesg: Aug 7 09:43:35 firewall /kernel: Copyright (c) 1992-2001 The FreeBSD Project. Aug 7 09:43:35 firewall /kernel: Copyright (c) 1979, 1
