Re: Possible bug - GRE tunnel routing
Hi Julian, Julian Elischer wrote: > Todor Genov wrote: >> Hi everyone, >> >> I may have found a routing bug relating to GRE tunnels. Could somebody >> try and replicate this? >> >> As per the setup below GRE-encapsulated traffic to 194.31.254.148 >> should be going out via tun1, but a tcpdump shows the traffic leaving >> via tun0. Any other traffic (icmp, tcp etc) destined to 194.31.154.148 >> goes out via tun1 as expected. >> >> Configuration: >> FreeBSD 7.0-STABLE #4: Mon Aug 18 13:50:38 SAST 2008 >> tun0 - PPPoE connection to ISP >> tun1 - vpn connection to office PIX (via vpnc) >> gre0 - GRE tunnel to machine sitting behind the PIX >> >> tun0: flags=8051 metric 0 mtu 1492 >> inet 41.142.82.37 --> 41.142.82.1 netmask 0xff00 >> Opened by PID 509 >> tun1: flags=8051 metric 0 mtu 1500 >> inet 194.31.137.70 --> 194.31.137.64 netmask 0xff40 >> Opened by PID 984 > > Point to point interfaces really don't have netmasks. > Otherwise it wouldn't be "Point to Point", it would be > "multicast" like ethernet. > > There is really only one address at this end or the other end. > If you want to say that there is a network at the other end > then you really need to set a route for it. > but it applies equally to all three of these p2p links. > > so, add a route: > > route add 92.168.254.0/24 92.168.254.1 The netmask for tun0 is automatically assigned by the ISP, and for tun1 by the VPN server. The one for gre0 is a /30 in the connect scripts - I must have changed it to /24 somewhere along the troubleshooting process - it makes no difference to the end result. The routing table does include routes to the /26 on tun1 and the /24 on gre0. I have left them out as they are not relevant to the problem. The troublesome route is the one to 194.31.154.148/32 Just noticed that the PtP address for tun1 looks incorrect - with that netmask into account .64 is the network address. I'll look into that as a possible cause. > > > >> gre0: flags=9051 metric 0 mtu >> 1476 >> tunnel inet 194.31.137.70 --> 194.31.154.148 >> inet 192.168.254.2 --> 92.168.254.1 netmask 0xff00 >> >> Routing table: >> DestinationGatewayFlagsRefs Use Netif >> Expire >> default41.142.82.1UGS 1 1365 tun0 >> 41.142.82.141.142.82.37 UGH 10 tun0 >> 192.168.254.1 192.168.254.2 UH 03 gre0 >> 194.31.137.64 194.31.137.70 UH 10 tun1 >> 194.31.154.148 194.31.137.64 UGS 00 tun1 >> >> GRE traffic (generated by ping -S 192.168.254.2 192.168.254.1) is routed >> via tun0 > > Why do you think you need -S? routing takes into account only the > destination.. > I am using -S just to make sure that the source IP is the gre0 interface - more of a habit than any particular reason. >> >> [EMAIL PROTECTED] ~]# tcpdump -ni tun0 proto gre >> tcpdump: verbose output suppressed, use -v or -vv for full protocol >> decode >> listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes >> 23:14:58.700415 IP 194.31.137.70 > 194.31.154.148: GREv0, length 88: IP >> 192.168.254.2 > 192.168.254.1: ICMP echo request, id 61956, seq 777, >> length 64 >> >> >> ICMP traffic (generated by ping -S 194.31.137.70 194.31.154.148) is >> routed via tun1 >> >> [EMAIL PROTECTED] ~]# tcpdump -ni tun1 icmp >> tcpdump: verbose output suppressed, use -v or -vv for full protocol >> decode >> listening on tun1, link-type NULL (BSD loopback), capture size 96 bytes >> 23:15:50.328470 IP 194.31.137.70 > 196.31.154.148: ICMP echo request, id >> 10757, seq 14, length 64 >> 23:15:50.340888 IP 196.31.154.148 > 194.31.137.70: ICMP echo reply, id >> 10757, seq 14, length 64 >> >> >> However, if I add a /24 route for the GRE endpoint subnet, instead of a >> /32 to the host: >> >> 194.31.154.0/24194.31.137.64 UGS 00 tun1 >> >> and then bring up the GRE tunnel, everything works as expected and GRE >> traffic exits via tun1. > > yes.. that is as expected.. It is also expected that the /32 route over tun1 to the GRE endpoint (196.31.154.148) should suffice. What puzzles me is the fact that GRE traffic to 196.31.154.138 leaves via tun0 and icmp traffic leaves via tun1. > >> >> >> > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
possibly bridge related problem
Hi, I have strange network problem on my laptop. I can't make connection to my desktop(192.168.0.18) from my laptop. However I can ping to other addresses from my laptop. I can't ping and make connection to my laptop from my desktop either. On the laptop I have bridge created at boot time. When I destroy bridge0 I can ping and make connection to my desktop. Is this known problem? If not where should I look for the problem? Or am I doing something wrong? ... devil# uname -an FreeBSD devil.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #8: Tue Aug 19 15:29:26 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEVIL i386 devil# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.920 ms 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=1.788 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=1.130 ms ^C --- 192.168.0.1 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.920/1.279/1.788/0.370 ms devil# ping 192.168.0.18 PING 192.168.0.18 (192.168.0.18): 56 data bytes ^C --- 192.168.0.18 ping statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss devil# ifconfig -a bge0: flags=8943 metric 0 mtu 1500 options=98 ether 00:14:22:fb:32:a6 inet 192.168.0.35 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff00 bridge0: flags=8843 metric 0 mtu 1500 ether 00:14:22:fb:32:a6 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143 ifmaxaddr 0 port 4 priority 128 path cost 200 member: bge0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 2 tap0: flags=8902 metric 0 mtu 1500 ether 00:bd:4b:1b:00:00 tun0: flags=8051 metric 0 mtu 1500 inet 192.168.10.34 --> 192.168.10.33 netmask 0x Opened by PID 802 devil# kldstat Id Refs AddressSize Name 1 22 0xc040 701a64 kernel 21 0xc0b02000 5844 if_tap.ko 31 0xc0b08000 15524snd_hda.ko 42 0xc0b1e000 52a08sound.ko 52 0xc0b71000 10ebcdrm.ko 61 0xc0b82000 71c4 i915.ko 71 0xc0b8a000 1fe68kqemu.ko 81 0xc0baa000 b8c8 aio.ko 91 0xc0bb6000 6b3d0acpi.ko 101 0xc433b000 9000 if_bridge.ko 111 0xc4344000 6000 bridgestp.ko 122 0xc44c2000 d000 ipfw.ko 131 0xc44fb000 4000 ipdivert.ko 141 0xc452a000 22000linux.ko 151 0xc45a6000 e000 fuse.ko devil# more /etc/rc.conf cloned_interfaces="bridge0 tap0" firewall_enable="YES" firewall_quiet="NO" firewall_script="/etc/rc.firewall" firewall_type="open" gateway_enable="YES" hostname="devil.micom.mng.net" ifconfig_bge0="DHCP" ifconfig_bridge0="addm bge0 addm tap0 up" inetd_enable="YES" natd_enable="YES"# Enable natd (if firewall_enable == YES). natd_interface="bge0" # Public interface or IPaddress to use. openvpn_enable="YES" openvpn_if="tun" devil# ipfw show 00050 224 19723 divert 8668 ip4 from any to any via bge0 00100 4 200 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 65000 383 33187 allow ip from any to any 65535 0 0 deny ip from any to any devil# netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default192.168.0.1UGS 0 205 bge0 127.0.0.1 127.0.0.1 UH 02lo0 192.168.0.0/24 link#1 UC 00 bge0 192.168.0.100:e0:29:3b:5a:b0 UHLW2 10 bge0 1099 192.168.10.0/24192.168.10.33 UGS 00 tun0 192.168.10.33 192.168.10.34 UH 10 tun0 ... thanks, Ganbold -- Algol-60 surely must be regarded as the most important programming language yet developed. -- T. Cheatham ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: possibly bridge related problem
2008/8/19 Ganbold <[EMAIL PROTECTED]>: > Hi, > > I have strange network problem on my laptop. > I can't make connection to my desktop(192.168.0.18) from my laptop. > However I can ping to other addresses from my laptop. > I can't ping and make connection to my laptop from my desktop either. > > On the laptop I have bridge created at boot time. > When I destroy bridge0 I can ping and make connection to my desktop. > Is this known problem? If not where should I look for the problem? > Or am I doing something wrong? > > ... > devil# uname -an FreeBSD devil.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE > #8: Tue Aug 19 15:29:26 ULAT 2008 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEVIL i386 > devil# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes > 64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.920 ms > 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=1.788 ms > 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=1.130 ms > ^C > --- 192.168.0.1 ping statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.920/1.279/1.788/0.370 ms > > devil# ping 192.168.0.18 PING 192.168.0.18 (192.168.0.18): 56 data bytes > ^C > --- 192.168.0.18 ping statistics --- > 4 packets transmitted, 0 packets received, 100.0% packet loss > > devil# ifconfig -a bge0: > flags=8943 metric 0 mtu 1500 > options=98 > ether 00:14:22:fb:32:a6 > inet 192.168.0.35 netmask 0xff00 broadcast 192.168.0.255 > media: Ethernet autoselect (1000baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > inet 127.0.0.1 netmask 0xff00 bridge0: > flags=8843 metric 0 mtu 1500 > ether 00:14:22:fb:32:a6 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap0 flags=143 > ifmaxaddr 0 port 4 priority 128 path cost 200 > member: bge0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 2 > tap0: flags=8902 metric 0 mtu 1500 > ether 00:bd:4b:1b:00:00 > tun0: flags=8051 metric 0 mtu 1500 > inet 192.168.10.34 --> 192.168.10.33 netmask 0x Opened by PID > 802 > > devil# kldstat Id Refs AddressSize Name > 1 22 0xc040 701a64 kernel > 21 0xc0b02000 5844 if_tap.ko > 31 0xc0b08000 15524snd_hda.ko > 42 0xc0b1e000 52a08sound.ko > 52 0xc0b71000 10ebcdrm.ko > 61 0xc0b82000 71c4 i915.ko > 71 0xc0b8a000 1fe68kqemu.ko > 81 0xc0baa000 b8c8 aio.ko > 91 0xc0bb6000 6b3d0acpi.ko > 101 0xc433b000 9000 if_bridge.ko > 111 0xc4344000 6000 bridgestp.ko > 122 0xc44c2000 d000 ipfw.ko > 131 0xc44fb000 4000 ipdivert.ko > 141 0xc452a000 22000linux.ko > 151 0xc45a6000 e000 fuse.ko > > devil# more /etc/rc.conf > cloned_interfaces="bridge0 tap0" > firewall_enable="YES" > firewall_quiet="NO" > firewall_script="/etc/rc.firewall" > firewall_type="open" > gateway_enable="YES" > hostname="devil.micom.mng.net" > > ifconfig_bge0="DHCP" > ifconfig_bridge0="addm bge0 addm tap0 up" > inetd_enable="YES" > > natd_enable="YES"# Enable natd (if firewall_enable == YES). > natd_interface="bge0" # Public interface or IPaddress to use. > openvpn_enable="YES" > openvpn_if="tun" > > > devil# ipfw show 00050 224 19723 divert 8668 ip4 from any to any via bge0 > 00100 4 200 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 > 65000 383 33187 allow ip from any to any > 65535 0 0 deny ip from any to any > > devil# netstat -rn Routing tables > > Internet: > DestinationGatewayFlagsRefs Use Netif Expire > default192.168.0.1UGS 0 205 bge0 > 127.0.0.1 127.0.0.1 UH 02lo0 > 192.168.0.0/24 link#1 UC 00 bge0 > 192.168.0.100:e0:29:3b:5a:b0 UHLW2 10 bge0 1099 > 192.168.10.0/24192.168.10.33 UGS 00 tun0 > 192.168.10.33 192.168.10.34 UH 10 tun0 > Hi, I guess you got that buggy window in 7-stable between [1] and the fix, that would come [2] in 7-stable in a few days. [1] http://svn.freebsd.org/viewvc/base?view=revision&revision=180364 [2] http://svn.freebsd.org/viewvc/base?view=revision&revision=181824 wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: possibly bridge related problem
pluknet wrote: 2008/8/19 Ganbold <[EMAIL PROTECTED]>: Hi, I have strange network problem on my laptop. I can't make connection to my desktop(192.168.0.18) from my laptop. However I can ping to other addresses from my laptop. I can't ping and make connection to my laptop from my desktop either. On the laptop I have bridge created at boot time. When I destroy bridge0 I can ping and make connection to my desktop. Is this known problem? If not where should I look for the problem? Or am I doing something wrong? ... devil# uname -an FreeBSD devil.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #8: Tue Aug 19 15:29:26 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEVIL i386 devil# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.920 ms 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=1.788 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=1.130 ms ^C --- 192.168.0.1 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.920/1.279/1.788/0.370 ms devil# ping 192.168.0.18 PING 192.168.0.18 (192.168.0.18): 56 data bytes ^C --- 192.168.0.18 ping statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss devil# ifconfig -a bge0: flags=8943 metric 0 mtu 1500 options=98 ether 00:14:22:fb:32:a6 inet 192.168.0.35 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff00 bridge0: flags=8843 metric 0 mtu 1500 ether 00:14:22:fb:32:a6 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143 ifmaxaddr 0 port 4 priority 128 path cost 200 member: bge0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 2 tap0: flags=8902 metric 0 mtu 1500 ether 00:bd:4b:1b:00:00 tun0: flags=8051 metric 0 mtu 1500 inet 192.168.10.34 --> 192.168.10.33 netmask 0x Opened by PID 802 devil# kldstat Id Refs AddressSize Name 1 22 0xc040 701a64 kernel 21 0xc0b02000 5844 if_tap.ko 31 0xc0b08000 15524snd_hda.ko 42 0xc0b1e000 52a08sound.ko 52 0xc0b71000 10ebcdrm.ko 61 0xc0b82000 71c4 i915.ko 71 0xc0b8a000 1fe68kqemu.ko 81 0xc0baa000 b8c8 aio.ko 91 0xc0bb6000 6b3d0acpi.ko 101 0xc433b000 9000 if_bridge.ko 111 0xc4344000 6000 bridgestp.ko 122 0xc44c2000 d000 ipfw.ko 131 0xc44fb000 4000 ipdivert.ko 141 0xc452a000 22000linux.ko 151 0xc45a6000 e000 fuse.ko devil# more /etc/rc.conf cloned_interfaces="bridge0 tap0" firewall_enable="YES" firewall_quiet="NO" firewall_script="/etc/rc.firewall" firewall_type="open" gateway_enable="YES" hostname="devil.micom.mng.net" ifconfig_bge0="DHCP" ifconfig_bridge0="addm bge0 addm tap0 up" inetd_enable="YES" natd_enable="YES"# Enable natd (if firewall_enable == YES). natd_interface="bge0" # Public interface or IPaddress to use. openvpn_enable="YES" openvpn_if="tun" devil# ipfw show 00050 224 19723 divert 8668 ip4 from any to any via bge0 00100 4 200 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 65000 383 33187 allow ip from any to any 65535 0 0 deny ip from any to any devil# netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default192.168.0.1UGS 0 205 bge0 127.0.0.1 127.0.0.1 UH 02lo0 192.168.0.0/24 link#1 UC 00 bge0 192.168.0.100:e0:29:3b:5a:b0 UHLW2 10 bge0 1099 192.168.10.0/24192.168.10.33 UGS 00 tun0 192.168.10.33 192.168.10.34 UH 10 tun0 Hi, I guess you got that buggy window in 7-stable between [1] and the fix, that would come [2] in 7-stable in a few days. [1] http://svn.freebsd.org/viewvc/base?view=revision&revision=180364 [2] http://svn.freebsd.org/viewvc/base?view=revision&revision=181824 Thanks a lot. After applying the patch it seems it is working OK now :) Ganbold wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- The Pig, if I am not mistaken, Gives us ham and pork and Bacon. Let others think his heart is big, I think it stupid of the Pig. -- Ogden Nash ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw add skipto tablearg....
On Thu, 31 Jul 2008, Julian Elischer wrote:
> looking int he code I noticed that the following command gave
> no error but didn't work..
>
>
> ipfw add 1000 skipto tablearg ip from any to table(31)
Content addressible branching is an elegant and useful idea, thanks for
making it work. A simple example in ipfw(8) might promote 'uptake'?
> and as I have a use for that, I implemented it..
MFC to 6 possible? likely? I know there's lots of other stuff that
hasn't / won't / can't be, but this one looked perhaps stand-alone ..
> see attached patch... (hopefully not stripped)
>
> Of course it is hoped that the rules you are skipping to are nearby
> as it iterates through the rules following the skipto to find the
> target,
Until $someone adds a direct skipto target jump at the virtual machine
code level - big recalc hit when adding/deleting rules/sets I suppose -
it's still the fastest way to get from a to b, where b > a
Speaking of which, should ipfw whinge when asked to skip backwards,
which it can't, confirmed on a recent browse re Mike's ipfw-classifyd
and a local test months ago.
> but
> if you had a thousand table entries and wanted to sort them into
> 20 buckets, it could save you puting them into 20 different
> tables and doing 20 table lookups on them.
Or even just for quick basic traffic-splitting, bogon lists, whatever ..
> here I sort into two categories.. possibly already a win..
>
>
> [EMAIL PROTECTED]:cat ipfw-test.sh
> #!/bin/sh
> ipfw add 100 skipto 1 ip from any to not 1.1.1.0/24
> ipfw add 1000 skipto tablearg ip from any to "table(31)"
> ipfw add 2000 drop ip from any to any
> ipfw add 2001 drop ip from any to any
> ipfw add 3000 drop ip from any to any
> ipfw add 3001 drop ip from any to any
> ipfw add 1 count ip from any to any
> ipfw table 31 add 1.1.1.1 2000
> ipfw table 31 add 1.1.1.2 3000
>
> [EMAIL PROTECTED]: ping 1.1.1.1
> [...] (2 packets bounced)
> [EMAIL PROTECTED]: ping 1.1.1.2
> [...] (12 packets bounced)
>
> [EMAIL PROTECTED]: ipfw show
> 00100 220 19633 skipto 1 ip from any to not 1.1.1.0/24
> 01000 14 1176 skipto tablearg ip from any to table(31)
> 020002168 deny ip from any to any
> 020010 0 deny ip from any to any
> 03000 12 1008 deny ip from any to any
> 030010 0 deny ip from any to any
> 1 209 18549 count ip from any to any
> 65535 1751 153792 allow ip from any to any
>
>
> comments?
I like it, FWIW.
> +if (tablearg != 0) {
> +rulenum = (u_int16_t)tablearg;
Should we check that tablearg is < 64K before merrily casting?
cheers, Ian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw add skipto tablearg....
On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: > On Thu, 31 Jul 2008, Julian Elischer wrote: ... > > ipfw add 1000 skipto tablearg ip from any to table(31) ... > > see attached patch... (hopefully not stripped) > > > > Of course it is hoped that the rules you are skipping to are nearby > > as it iterates through the rules following the skipto to find the > > target, > > Until $someone adds a direct skipto target jump at the virtual machine > code level - big recalc hit when adding/deleting rules/sets I suppose - > it's still the fastest way to get from a to b, where b > a you mean with tables-based skipto targets ? Because the regular skipto has been a constant-time op forever, even in ipfw1 i believe, invalidating the target cache on a change and recomputing it the fly at the first request. > Speaking of which, should ipfw whinge when asked to skip backwards, > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd > and a local test months ago. right... but the error can only be reliably detected in the kernel, as the rule number is not always known when the rule is added. cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw add skipto tablearg....
On Tue, 19 Aug 2008, Luigi Rizzo wrote: > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: > > On Thu, 31 Jul 2008, Julian Elischer wrote: > ... > > > ipfw add 1000 skipto tablearg ip from any to table(31) > ... > > > see attached patch... (hopefully not stripped) > > > > > > Of course it is hoped that the rules you are skipping to are nearby > > > as it iterates through the rules following the skipto to find the > > > target, > > > > Until $someone adds a direct skipto target jump at the virtual machine > > code level - big recalc hit when adding/deleting rules/sets I suppose - > > it's still the fastest way to get from a to b, where b > a > > you mean with tables-based skipto targets ? Because the regular > skipto has been a constant-time op forever, even in ipfw1 i believe, > invalidating the target cache on a change and recomputing it the > fly at the first request. Thanks; I'd completely missed the caching of skipto targets before, and it's all so well commented too. blushing, but glad for the good news. But yes I was pondering Julian's patch, which has to lookup_next_rule every time, and also Mike's bending of divert reentry rule number in ipfw-classifyd with similar intent, which also has to hunt forward in linear time for its target rule - or am I missing something else here? > > Speaking of which, should ipfw whinge when asked to skip backwards, > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd > > and a local test months ago. > > right... but the error can only be reliably detected in the kernel, > as the rule number is not always known when the rule is added. Yes I meant at run-time. On second thoughts, it'd be too easy a way to spam syslogd in the general case, but maybe reporting target < current rule for such dynamic forms of skipto might highlight config errors? I should STFU and resume lurking unless I can contribute code, I know. cheers, Ian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible bug - GRE tunnel routing
Todor Genov wrote: Hi Julian, Julian Elischer wrote: Todor Genov wrote: Hi everyone, I may have found a routing bug relating to GRE tunnels. Could somebody try and replicate this? As per the setup below GRE-encapsulated traffic to 194.31.254.148 should be going out via tun1, but a tcpdump shows the traffic leaving via tun0. Any other traffic (icmp, tcp etc) destined to 194.31.154.148 goes out via tun1 as expected. Configuration: FreeBSD 7.0-STABLE #4: Mon Aug 18 13:50:38 SAST 2008 tun0 - PPPoE connection to ISP tun1 - vpn connection to office PIX (via vpnc) gre0 - GRE tunnel to machine sitting behind the PIX tun0: flags=8051 metric 0 mtu 1492 inet 41.142.82.37 --> 41.142.82.1 netmask 0xff00 Opened by PID 509 tun1: flags=8051 metric 0 mtu 1500 inet 194.31.137.70 --> 194.31.137.64 netmask 0xff40 Opened by PID 984 Point to point interfaces really don't have netmasks. Otherwise it wouldn't be "Point to Point", it would be "multicast" like ethernet. There is really only one address at this end or the other end. If you want to say that there is a network at the other end then you really need to set a route for it. but it applies equally to all three of these p2p links. so, add a route: route add 92.168.254.0/24 92.168.254.1 The netmask for tun0 is automatically assigned by the ISP, and for tun1 by the VPN server. The one for gre0 is a /30 in the connect scripts - I must have changed it to /24 somewhere along the troubleshooting process - it makes no difference to the end result. let me rephrase that.. p2p links do not support netmasks. That's all p2p links.. ppp, slip, tun, ng, gre, etc. If you what a virtual ethernet interface you may try tap(4) but you will need to have an appropriatly capable piece of software on the other end of the link. A p2p link doesn't take any notice of what you have written as netmask and it doesn't matter what your ISP has given you, or if you type /24 or /22 or /32. The point to point interface only knows about the ONE SINGLE ADDRESS on the other end of the link. If there is a network there, which that address is a part of, then it is up to YOU to add the route that allows packets to get there. The routing table does include routes to the /26 on tun1 and the /24 on gre0. I have left them out as they are not relevant to the problem. The troublesome route is the one to 194.31.154.148/32 Just noticed that the PtP address for tun1 looks incorrect - with that netmask into account .64 is the network address. I'll look into that as a possible cause. the netmask should not be taken into account because it is ignored. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw add skipto tablearg....
On Wed, Aug 20, 2008 at 04:06:05AM +1000, Ian Smith wrote: > On Tue, 19 Aug 2008, Luigi Rizzo wrote: > > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: ... > > > Until $someone adds a direct skipto target jump at the virtual machine > > > code level - big recalc hit when adding/deleting rules/sets I suppose - > > > it's still the fastest way to get from a to b, where b > a > > > > you mean with tables-based skipto targets ? Because the regular > > skipto has been a constant-time op forever, even in ipfw1 i believe, > > invalidating the target cache on a change and recomputing it the > > fly at the first request. > > Thanks; I'd completely missed the caching of skipto targets before, and > it's all so well commented too. blushing, but glad for the good news. > > But yes I was pondering Julian's patch, which has to lookup_next_rule > every time, and also Mike's bending of divert reentry rule number in > ipfw-classifyd with similar intent, which also has to hunt forward in > linear time for its target rule - or am I missing something else here? well, you can use a hash table to support that. It shouldn't be so bad to implement, flow tables already use hash tables so one can reuse the same code. > > > Speaking of which, should ipfw whinge when asked to skip backwards, > > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd > > > and a local test months ago. > > > > right... but the error can only be reliably detected in the kernel, > > as the rule number is not always known when the rule is added. > > Yes I meant at run-time. On second thoughts, it'd be too easy a way to actually you can do it at insertion time, it's just that you cannot do it in userland as other checks before inserting the rule. cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw add skipto tablearg....
Luigi Rizzo wrote: On Wed, Aug 20, 2008 at 04:06:05AM +1000, Ian Smith wrote: On Tue, 19 Aug 2008, Luigi Rizzo wrote: > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: ... > > Until $someone adds a direct skipto target jump at the virtual machine > > code level - big recalc hit when adding/deleting rules/sets I suppose - > > it's still the fastest way to get from a to b, where b > a > > you mean with tables-based skipto targets ? Because the regular > skipto has been a constant-time op forever, even in ipfw1 i believe, > invalidating the target cache on a change and recomputing it the > fly at the first request. Thanks; I'd completely missed the caching of skipto targets before, and it's all so well commented too. blushing, but glad for the good news. But yes I was pondering Julian's patch, which has to lookup_next_rule every time, and also Mike's bending of divert reentry rule number in ipfw-classifyd with similar intent, which also has to hunt forward in linear time for its target rule - or am I missing something else here? well, you can use a hash table to support that. It shouldn't be so bad to implement, flow tables already use hash tables so one can reuse the same code. one COULD, but I know I use this feature only with a number (20 or less) following rules, each of which is a skipto itself to some further awat location...or a simple drop.. Shall we say we "leave it as an exercise for the reader" ? > > Speaking of which, should ipfw whinge when asked to skip backwards, > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd > > and a local test months ago. > > right... but the error can only be reliably detected in the kernel, > as the rule number is not always known when the rule is added. Yes I meant at run-time. On second thoughts, it'd be too easy a way to actually you can do it at insertion time, it's just that you cannot do it in userland as other checks before inserting the rule. cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw add skipto tablearg....
Luigi Rizzo wrote: On Wed, Aug 20, 2008 at 04:06:05AM +1000, Ian Smith wrote: On Tue, 19 Aug 2008, Luigi Rizzo wrote: > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: ... > > Until $someone adds a direct skipto target jump at the virtual machine > > code level - big recalc hit when adding/deleting rules/sets I suppose - > > it's still the fastest way to get from a to b, where b > a > > you mean with tables-based skipto targets ? Because the regular > skipto has been a constant-time op forever, even in ipfw1 i believe, > invalidating the target cache on a change and recomputing it the > fly at the first request. Thanks; I'd completely missed the caching of skipto targets before, and it's all so well commented too. blushing, but glad for the good news. But yes I was pondering Julian's patch, which has to lookup_next_rule every time, and also Mike's bending of divert reentry rule number in ipfw-classifyd with similar intent, which also has to hunt forward in linear time for its target rule - or am I missing something else here? well, you can use a hash table to support that. It shouldn't be so bad to implement, flow tables already use hash tables so one can reuse the same code. > > Speaking of which, should ipfw whinge when asked to skip backwards, > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd > > and a local test months ago. > > right... but the error can only be reliably detected in the kernel, > as the rule number is not always known when the rule is added. Yes I meant at run-time. On second thoughts, it'd be too easy a way to actually you can do it at insertion time, it's just that you cannot do it in userland as other checks before inserting the rule. you can't do it at insertion time if it's a tablearg style skipto.. but such a rule will simply continue at the next rule as if it did not match. cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible bug - GRE tunnel routing
Julian Elischer wrote: > Todor Genov wrote: >> Hi Julian, > let me rephrase that.. > p2p links do not support netmasks. That's all p2p links.. ppp, slip, > tun, ng, gre, etc. > > If you what a virtual ethernet interface you may try tap(4) but you will > need to have an appropriatly capable piece of software on the > other end of the link. > > > A p2p link doesn't take any notice of what you have written as netmask > and it doesn't matter what your ISP has given you, or if you > type /24 or /22 or /32. > > The point to point interface only knows about the ONE SINGLE ADDRESS > on the other end of the link. > If there is a network there, which that address is a part of, then > it is up to YOU to add the route that allows packets to get there. > > This is fully understood and taken into account. For all intended purposes I treat the tunnels as a /30 subnets (despite what ifconfig says) and as per the routing table which I pasted destinations which need to be reached over those tunnels have static routes specified: default41.142.82.1UGS 1 1365 tun0 41.142.82.141.142.82.37 UGH 10 tun0 192.168.254.1 192.168.254.2 UH 03 gre0 194.31.137.64 194.31.137.70 UH 10 tun1 194.31.154.148 194.31.137.64 UGS 00 tun1 ^^^ this is the other end of the GRE tunnel From this routing table alone there is no way that traffic destined to 196.31.154.148 should exit via tun0, but GRE traffic to 194.31.154.148 does. >> >> The routing table does include routes to the /26 on tun1 and the /24 on >> gre0. I have left them out as they are not relevant to the problem. The >> troublesome route is the one to 194.31.154.148/32 >> >> Just noticed that the PtP address for tun1 looks incorrect - with that >> netmask into account .64 is the network address. I'll look into that as >> a possible cause. > > the netmask should not be taken into account because it is ignored. I was referring to static routes, not interface addressing in the above. Those routes also exist in my routing table, even though I omitted them in my original paste 192.168.254.0/24 192.168.254.1 UGS 00 gre0 196.31.137.64/26 196.30.157.65 UGS 00 tun1 (which i omitted in my original paste). Both those routes are irrelevant as the GRE endpoint is not these subnets - it's merely reachable via tun1 -- Regards, Todor Genov Systems Operations Verizon Business South Africa (Pty) Ltd [EMAIL PROTECTED] Tel: +27 11 235 6500 Fax: 086 692 0543 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible bug - GRE tunnel routing
Todor Genov wrote:
Julian Elischer wrote:
Todor Genov wrote:
Hi Julian,
let me rephrase that..
p2p links do not support netmasks. That's all p2p links.. ppp, slip,
tun, ng, gre, etc.
If you what a virtual ethernet interface you may try tap(4) but you will
need to have an appropriatly capable piece of software on the
other end of the link.
A p2p link doesn't take any notice of what you have written as netmask
and it doesn't matter what your ISP has given you, or if you
type /24 or /22 or /32.
The point to point interface only knows about the ONE SINGLE ADDRESS
on the other end of the link.
If there is a network there, which that address is a part of, then
it is up to YOU to add the route that allows packets to get there.
This is fully understood and taken into account.
For all intended purposes I treat the tunnels as a /30 subnets
there you go again...
tunnels are NOT SUBNETS OF ANY TYPE
the two ends can be in completely different address spaces..
one can be 10.2.2.2 and the other end can be 192.168.2.42
there is NO SUBNETTING on point to point interfaces..
(despite what ifconfig says) and as per the routing table which I pasted
destinations which need to be reached over those tunnels have static
routes specified:
default41.142.82.1UGS 1 1365 tun0
41.142.82.141.142.82.37 UGH 10 tun0
192.168.254.1 192.168.254.2 UH 03 gre0
194.31.137.64 194.31.137.70 UH 10 tun1
194.31.154.148 194.31.137.64 UGS 00 tun1
^^^ this is the other end of the GRE tunnel
From this routing table alone there is no way that traffic destined to
196.31.154.148 should exit via tun0, but GRE traffic to 194.31.154.148 does.
196?
I've deleted you original mail.. sorry..
Resend me privately the output of ifconfig -a and
the FULL netstat -r output..
The routing table does include routes to the /26 on tun1 and the /24 on
gre0. I have left them out as they are not relevant to the problem. The
troublesome route is the one to 194.31.154.148/32
Just noticed that the PtP address for tun1 looks incorrect - with that
netmask into account .64 is the network address. I'll look into that as
a possible cause.
the netmask should not be taken into account because it is ignored.
I was referring to static routes, not interface addressing in the above.
so why are you setting netmasks. actually I see a bug, which is that
ifconfig -a shows a netmask no matter if it makes sense..
Those routes also exist in my routing table, even though I omitted them
in my original paste
192.168.254.0/24 192.168.254.1 UGS 00 gre0
196.31.137.64/26 196.30.157.65 UGS 00 tun1
(which i omitted in my original paste).
Both those routes are irrelevant as the GRE endpoint is not these
subnets - it's merely reachable via tun1
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
7-STABLE lock order reversal
(Reposting to -net as suggested by Kris.) 7.0-STABLE #0: Tue Aug 19 20:39:48 CEST 2008 After system update from June 12 sources to Aug 12 I have seen frequent lockups during network operations. Compiled debugging kernel and got the below during boot. Should I open a PR? Suggestions welcome. Thanks. Aug 19 22:12:47 kreutzman kernel: uhid0: on uhub5 Aug 19 22:12:47 kreutzman kernel: lock order reversal: Aug 19 22:12:47 kreutzman kernel: 1st 0xc7077a14 rtentry (rtentry) @ /usr/src/sys/net/route.c:328 Aug 19 22:12:47 kreutzman kernel: 2nd 0xc6eee07c radix node head (radix node head) @ /usr/src/sys/net/route.c:879 Aug 19 22:12:47 kreutzman kernel: KDB: stack backtrace: Aug 19 22:12:47 kreutzman kernel: db_trace_self_wrapper(c0af8084,e71f5a4c,c07a777e,c0afa653,c6eee07c,...) at db_trace_self_wrapper+0x26 Aug 19 22:12:47 kreutzman kernel: kdb_backtrace(c0afa653,c6eee07c,c0afa6b4,c0afa6b4,c0b031c2,...) at kdb_backtrace+0x29 Aug 19 22:12:47 kreutzman kernel: witness_checkorder(c6eee07c,9,c0b031c2,36f,c6c5f2b8,...) at witness_checkorder+0x6de Aug 19 22:12:47 kreutzman kernel: _mtx_lock_flags(c6eee07c,0,c0b031c2,36f,c0af3ca5,...) at _mtx_lock_flags+0xbc Aug 19 22:12:47 kreutzman kernel: rtrequest1_fib(1,e71f5ae8,e71f5b18,0,ce,...) at rtrequest1_fib+0x82 Aug 19 22:12:47 kreutzman kernel: rtredirect_fib(e71f5bb8,e71f5ba8,0,16,e71f5b98,...) at rtredirect_fib+0x13d Aug 19 22:12:47 kreutzman kernel: in_rtredirect(e71f5bb8,e71f5ba8,0,6,e71f5b98,...) at in_rtredirect+0x34 Aug 19 22:12:47 kreutzman kernel: icmp_input(c7081d00,14,80246,c0bf53c0,e71f5c08,...) at icmp_input+0x526 Aug 19 22:12:47 kreutzman kernel: ip_input(c7081d00,14e,800,c6c89400,800,...) at ip_input+0x650 Aug 19 22:12:47 kreutzman kernel: netisr_dispatch(2,c7081d00,10,3,0,...) at netisr_dispatch+0x73 Aug 19 22:12:47 kreutzman kernel: ether_demux(c6c89400,c7081d00,3,0,3,...) at ether_demux+0x1f1 Aug 19 22:12:47 kreutzman kernel: ether_input(c6c89400,c7081d00,c0ac0c3e,c57,c6c89400,...) at ether_input+0x3d9 Aug 19 22:12:47 kreutzman kernel: bge_intr(c6c9,0,c0af18b8,442,c6b334e8,...) at bge_intr+0x7ca Aug 19 22:12:47 kreutzman kernel: ithread_loop(c6c946d0,e71f5d38,c0af1622,305,c6c97ad0,...) at ithread_loop+0x1c5 Aug 19 22:12:47 kreutzman kernel: fork_exit(c074ce40,c6c946d0,e71f5d38) at fork_exit+0xb8 Aug 19 22:12:47 kreutzman kernel: fork_trampoline() at fork_trampoline+0x8 Aug 19 22:12:47 kreutzman kernel: --- trap 0, eip = 0, esp = 0xe71f5d70, ebp = 0 --- Aug 19 22:12:47 kreutzman kernel: Expensive timeout(9) function: 0xc068b7f0(0xc0c82f00) 0.004460343 s Aug 19 22:12:47 kreutzman savecore: no dumps found ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Application layer classifier for ipfw
Ermal Luçi escreveu: On Sat, Aug 2, 2008 at 3:00 PM, Mike Makonnen <[EMAIL PROTECTED]> wrote: Mike Makonnen wrote: Patrick Tracanelli wrote: To let you know of my current (real world) tests: - Wireless Internet Provider 1: - 4Mbit/s of Internet Traffic - Classifying default protocols + soulseek + ssh - Classifying 100Mbit/s of dump over ssh Results in: No latency added, very low CPU usage, no packets dropping. - Wireless ISP 2: - 21 Mbit/s of Internet Traffic - Classifying default protocols + soulseek + ssh Results in: No tcp or udp traffic at all; everything that gets diverted never comes out of the divert socket, and ipfw-classifyd logs Aug 1 12:07:35 ourofino last message repeated 58 times Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent (rule 5) Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey (rule 5) Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack (rule 5) Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella (rule 1000) Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek (rule 5) Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule 5) Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert socket: Operation not permitted Aug 1 12:18:50 ourofino last message repeated 90 times Hmmm... this part means that the call to sendto(2) to write the packet back into network stack failed. This explains why you are not seein g any traffic comming back out of the divert socket, but I don't see why it would suddenly fail with a permission error. Could this be a kernel bug? Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue full Aug 1 12:19:11 ourofino last message repeated 94 times Raised queue len a lot (up to 40960), when the application starts it uses up to 25% CPU and a second after that, CPU usage gets lower the 0.1%. This looks like a deadlock. If it weren't able to process packets fast enough the cpu usage should be high even as it's spewing "packet dropped" messages. Can you send me some more information like memory usage and the firewall script you are using? How much of the 21Mbits/s of traffic is P2P? If you reduce the number of protocols you are trying to match against does the behavior change? Using netstat -w1 -I can you tell me how many packets per second we're talking about for 4Mbits/s and 21Mbit/s? Also, the timestamps from the log file seem to show that the daemon is running for approx. 34 sec. before the first "unable to write to write to divert socket" message. Is it passing traffic during this time? Thanks. I've uploaded a newer version. Can you try that also please. It includes: o SIGHUP forces it to re-read its configuration file o rc.d script o minor optimization (calls pthread_cond_signal with the mutex unlocked) o code cleanup Also, for your convenience I have attached a patch against the earlier version that removes a debugging printf that should remove spammage to your log files (the current version has it removed already). Ooops, a few minutes after I sent this email I found a couple of bugs (one major, and one minor). They were in the original tarball as well as the newer one I uploaded earlier today. I've uploaded a fixed version of the code. Can you try that instead please. Also, to help track down performance issues I've modified the Makefile to build a profiled version of the application so you can use gprof(1) to figure out where any problems lie. Does this sound about right for implementing the GC and implementing syntax as $protocol = dnpipe 20 $protocol2 = dnqueue 30 it has some extra goos for pf(4) and altq(4) $protocol3 = queue $queue name $protocol4 = tag TAGNAME $protocol5 = action block It adds 2 new options -e seconds for seconds before a flow is considered expired and -n #packets proccessed before kicking the GC. --- classifyd_old.c 2008-08-09 00:33:04.0 + +++ classifyd.c 2008-08-09 00:33:34.0 + @@ -28,13 +28,17 @@ #include #include +#include +#include +#include #include #include #include #include #include #include +#include #include #include @@ -53,6 +57,7 @@ #include #include "hashtable.h" +#include "hashtable_private.h" #include "pathnames.h" #include "protocols.h" @@ -94,6 +99,7 @@ uint32_t if_datalen;/* length in bytes of if_data */ uint16_t if_pktcount; /* number of packets concatenated */ uint16_t if_fwrule; /* ipfw(4) rule associated with flow */ + time_t expire;/* flow expire time */ }; /* @@ -126,7 +132,7 @@ static struct ic_queue outQ; /* divert(4) socket */ -static int dvtS; +static int dvtS = 0; /* config file path */ static const char *conf = IC_CONFIG_PATH; @@ -137,12 +143,25 @@ /* List of protocols available to the system */ struct ic_protocols *fp; +/* Our hashtables */ +struct ha
