fastforwarding and gif tunnel
Hi, I have an esp/tunnel between two sites. 192.168.1.0/24 -> 192.168.1.1 gif - esp/tunnel - gif 192.168.101.1 -> 192.168.101.0/24 If I ping 192.168.101.1 from the 192.168.1.1 gateway everything works. If I ping 192.168.101.2 from the 192.168.1.1 gateway everything works But if I ping from 192.168.1.x to 192.168.101.2 it doesn't setup the tunnel, nor does it use the tunnel when there. I have narrowed it down to the use of fastforwarding on 192.168.1.1. Without fastforwarding everything works, with fastforwarding it does not. Unfortunately I found out ICMP is not fastforwarded, so I didn't try a TCP or UDP test. I am running 7.0-RELEASE ( most recent, but it was broken before ). Is fastforwarding supposed to be compatible with gif tunnels, or is this a bug? Peter __ Information from ESET NOD32 Antivirus, version of virus signature database 2904 (20080227) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [RESOLVED] Re: Strange resolver behavior
Greetings, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 JINMEI Tatuya / 神明達哉 wrote: [snip] At the beginning I was confused with host(1) and resolver library, they are different problems, sorry for the confusion. I think Hajimu-san's analysis was correct that it was caused by the check in resolver, here is a ktrace output from a system without patched libc: http://www.delphij.net/kdump.txt Note that, with a patched (with ume@'s patch) resolver, the program *does* worked as expected, also this will make firefox to be able to resolve the domain name. Test program can be downloaded from http://www.delphij.net/test.c . With patched libc you will get no output (expected), and with unpatched libc you will get "Unknown server error" and will be unable to get the A RR. It turns out that the baidu.com DNS administrator might be unaware of the potential violation of RFC 952 "ASSUMPTIONS" and RFC 1034 Section 3.5. However, I am afraid that there are some DNS server implementations that does allow '_'s in domain names, so if there is no potential risks allowing it from the resolver side I think it might be a good idea to be more permissive for this case, because there are real uses of it, and other operating systems does allow it at the client side. Did you check http://tools.ietf.org/html/rfc2782 ? It is "PROPOSED STANDARD" and MS DNS in Win2003 already uses it (if you have domain controller for example). -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
interface aliases and tap devices
Hello, I have two stories to tell meanwhile, the first comes here in form of a forward from a question I posted on the discussion list for dnsmasq (ports/dns/dnsmasq): --- Begin forwarded message: Date: Wed, 27 Feb 2008 09:28:28 + From: Simon Kelley <[EMAIL PROTECTED]> To: Gerrit Kühn <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: [Dnsmasq-discuss] question about subnets and interface aliases Gerrit Kühn wrote: > Hi folks, > > I have a private network here (192.168.0.0/16) which I have separated > in 8 subnets (192.168.0.0/19, 192.168.32.0/19 and so on). I want to > run dnsmasq to serve as dns and dhcp server, but only on one machine. > As the separation of the subnets is purely of logical nature and not > physical (everything on the same switched network), I have configured > this machine with the primary IP address 192.168.0.254/19 and put IP > aliases for all other subnets (192.168.32.254/19 and so on) on that > interface. The free dhcp IP-range for unknown hosts is in the first > subnet (192.168.30.0/24), all others shall be fixed-host entries > which are identified via their MAC addresses. > > Now I see the following behaviour: dhcp-addresses are delivered from > the free segment to unknown hosts as designed. However, fixed-host > entries only work if they come from the first subnet > (192.168.0.0/19). If I have dhcp-host entries for any other subnet, > they are completely ignored and the requesting hosts gets an IP from > the free range for unknown hosts instead. > > Is my setup completely screwed up and something one should not do, or > does anyone here have an idea how to get things right? I'm using > FreeBSD 7-stable and dnsmasq 2.40 (if that matters). It does matter, specifically the FreeBSD bit. On Linux, the above arrangement will work, (or at least can be made to work). The code for determining the IP parameters of an interface on *BSD knows nothing about aliases, so it can't work. > Any hint is appreciated. If you are, or can find, a FreeBSD networking guru who can upgrade the code in src/bpf.c I'm happy to take a patch. Cheers, Simon. --- As I am definitely not the networking guru who could do this, I thought it would be a good idea to ask here if anyone is interested in helping out. The second story is connected with the first: As the problem for dnsmasq seems to be that it cannot handle more than one IP per interface, I came up with the idea if setting up one IP on the physical interface and 7 more on 7 virtual tap devices. Then I bound the tap devices together with the physical interface on a bridge interface. This setup works insofar that I can ping all 8 addresses and receive answers. ssh connections and so on work, too. However, the dhcp client broadcasts do not reach dnsmasq, although I configured it to listen on all 8 interfaces. Even more strange to me was that I discovered that the virtual tap interfaces see nothing of the traffic. If I run tcpdump on the tap devices (or even on the bridge interface), I see /nothing/ of the traffic which is actually directed to one of the IPs the tap devices carry. I see everything floating though the physical interface, though. I actually thought that the traffic would reach the tap interfaces and could be processed there with other software like tcpdump or dnsmasq. Why is this not the case? cu Gerrit ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [RESOLVED] Re: Strange resolver behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Lambrev wrote: [snip] > Did you check http://tools.ietf.org/html/rfc2782 ? > It is "PROPOSED STANDARD" and MS DNS in Win2003 already uses it (if you > have domain controller for example). If I have understood the RFC correctly, it talks about SRV RR and not A RR, and as far as I know, there is no RFC updated 1034 and 952 on this aspect. The same thing worked for FreeBSD's portsnap service at the very least, and also Yahoo's domain key, but neither is an A RR having underscore and, for many traditional Internet applications like sendmail, an A RR with underscore is rejected. I have made a change on -CURRENT and is waiting for comments from others to see if it's suitable for MFC, to make it possible to resolve an A RR with underscore symbol, instead of querying it and drop the result, and give the application an opportunity to choose between rejecting or allowing _'s when they are using gethostbyname(). Cheers, - -- Xin LI <[EMAIL PROTECTED]> http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHxapDi+vbBBjt66ARAsynAKCziDnfUYMsGTFHwWGMPrmLuguUtACgh/Wa z/AliWmZg1soCOa+kY4TPDg= =UDvY -END PGP SIGNATURE- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ephemeral port selection (patch)
On Mon, Feb 25, 2008 at 8:16 AM, Fernando Gont <[EMAIL PROTECTED]> wrote:
> Folks,
>
> This patch simply eliminates duplicated code in the in_pcb_bind() function.
>
> Index: in_pcb.c
> ===
> RCS file: /home/ncvs/src/sys/netinet/in_pcb.c,v
> retrieving revision 1.198
> diff -u -r1.198 in_pcb.c
> --- in_pcb.c22 Dec 2007 10:06:11 - 1.198
> +++ in_pcb.c25 Feb 2008 06:10:04 -
> @@ -393,7 +393,7 @@
> if (*lportp != 0)
> lport = *lportp;
> if (lport == 0) {
> - u_short first, last;
> + u_short first, last, aux;
> int count;
>
> if (laddr.s_addr != INADDR_ANY)
> @@ -440,47 +440,28 @@
> /*
> * Simple check to ensure all ports are not used up causing
> * a deadlock here.
> -*
> -* We split the two cases (up and down) so that the direction
> -* is not being tested on each round of the loop.
> */
> if (first > last) {
> - /*
> -* counting down
> -*/
> - if (dorandom)
> - *lastport = first -
> - (arc4random() % (first - last));
> - count = first - last;
> -
> - do {
> - if (count-- < 0)/* completely used?
> */
> - return (EADDRNOTAVAIL);
> - --*lastport;
> - if (*lastport > first || *lastport < last)
> - *lastport = first;
> - lport = htons(*lastport);
> - } while (in_pcblookup_local(pcbinfo, laddr, lport,
> - wild));
> - } else {
> - /*
> -* counting up
> -*/
> - if (dorandom)
> - *lastport = first +
> - (arc4random() % (last - first));
> - count = last - first;
> -
> - do {
> - if (count-- < 0)/* completely used?
> */
> - return (EADDRNOTAVAIL);
> - ++*lastport;
> - if (*lastport < first || *lastport > last)
> - *lastport = first;
> - lport = htons(*lastport);
> - } while (in_pcblookup_local(pcbinfo, laddr, lport,
> - wild));
> + aux = first;
> + first = last;
> + last = aux;
> }
> +
> + if (dorandom)
> + *lastport = first +
> + (arc4random() % (last - first));
> +
> + count = last - first;
> +
> + do {
> + if (count-- < 0)/* completely used? */
> + return (EADDRNOTAVAIL);
> + ++*lastport;
> + if (*lastport < first || *lastport > last)
> + *lastport = first;
> + lport = htons(*lastport);
> + } while (in_pcblookup_local(pcbinfo, laddr, lport,
> + wild));
> }
> if (prison_ip(cred, 0, &laddr.s_addr))
> return (EINVAL);
>
>
> --
> Fernando Gont
> e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
Yeah, you're right. I'll try to commit this.
Regards.
--
Rui Paulo
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vlan issues with 7.0-RC3
On Tue, Feb 26, 2008 at 04:43:55PM +0900, Pyun YongHyeon wrote: >On Mon, Feb 25, 2008 at 01:17:12AM -0800, Christopher Cowart wrote: >> Hello, >> >> I have a mac mini running 7.0-RC3, which I'm trying to turn it into a >> router. I have a Linksys SRW2008 "fully managed" (via an IE only web >> interface, ick) switch. >> >> Switch: >> Port 1 - Trunk vlans 10,60,98 - FreeBSD Box >> Port 7 - Access vlan 98 - Existing LAN (192.168.1.0/24) >> >> OpenWRT (192.168.1.1): >> WRT54G box on the Existing LAN >> >> FreeBSD Box: >> ifconfig msk0 up >> ifconfig vlan98 create vlan 98 vlandev msk0 inet 192.168.1.67/24 >> >> With this configuration, I can ping hosts on the other lan segment (Port >> 7). Arp and icmp seem to be quite happy. Unfortunately, I'm not having >> any luck with tcp and udp. Any attempt to ssh to OpenWRT or dig >> @OpenWRT hangs indefinitely. If I do a tcpdump, I see the SYN or A? >> leaving and absolutely no response returning. If I run a tcpdump on >> OpenWRT, I see no incoming traffic. >> >> When I try to connect *to* the FreeBSD box from the other lan segment, I >> continue to have problems. tcpdump shows the SYNs arriving via vlan98 >> and the FreeBSD box responding with SYN-ACK. OpenWRT receives the SYNACK. >> >> I disabled ipfw just to be sure (sysctl -w net.inet.ip.fw.enable=0), but >> it had no effect on the problem. If I connect the FreeBSD box to a vlan >> 98 access port and assign the address to msk0, my connectivity problems >> go away. This leads me to believe that the firewall on OpenWRT is not >> the problem and the problem is related to vlans. >> >> Thinking it was a problem with the not-so-cheap Linksys POS (bitterness >> about the IE web interface again), I plugged my MacBook (running >> Leopard, not FreeBSD) into the trunk port. Running the ifconfig commands >> above (s/msk0/en0/), I got up and running without any problems. This >> causes me to suspect the FreeBSD box. >> >> Does anyone have any idea what's going on here? Any suggestions for >> further troubleshooting? >> > > Try disabling hardware features one by one in msk(4) and see how > it goes. > o Disable TSO. > o Disable Tx checksum offload. > o Disable VLAN hardware tagging. Works great after `sudo ifconfig msk0 -txcsum'. Is this a known bug, or should I file a PR? Let me know if there are any other details I can provide to help somebody squash it. Thanks, -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley pgpjxTTp1C5Gv.pgp Description: PGP signature
