Re: kern/127529: [nfe] [patch] Summary of Nvidia 8200/MCP78S chipset, notably req nfe driver update
Synopsis: [nfe] [patch] Summary of Nvidia 8200/MCP78S chipset, notably req nfe driver update State-Changed-From-To: open-feedback State-Changed-By: yongari State-Changed-When: Mon Sep 22 06:25:38 UTC 2008 State-Changed-Why: Would you try patch at the followng URL? http://people.freebsd.org/~yongari/nfe/nfe.mcp77_79.patch Responsible-Changed-From-To: freebsd-net-yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Sep 22 06:25:38 UTC 2008 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=127529 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process.
On Sun, 21 Sep 2008, Chris Buechler wrote: This PR is bogus because: ICMP has no concept of datagrams being owned by a process. There is no field in the ICMP protocol which differentiates ICMP sessions on a per-process basis, and this is because ICMP has no concept of sessions -- ICMP messages are directed at IP endpoints. ICMP echo and echo replies do have sessions of sorts, at least unique identifying fields - identifier and sequence number. This was opened by a pfSense maintainer because it's a change in behavior from 6.x releases where this was never an issue, and is something we feel is a regression. Ideally you don't want to be pinging the same host from two different processes, but it's difficult to avoid in some circumstances and it's something that always worked fine prior to FreeBSD 7.0. As far as I'm aware, IP raw sockets have never supported using the ID field to identify sessions or direct packets to specific sockets. This means that a kernel regression in that session semantic is unlikely. However, it could be that you're seeing the impact of another regression relating to other behavior for restricting ICMP received on the raw socket. The kernel code in question is in raw_ip.c:rip_input(), which performs the following checks for each raw IP socket it considers a candidate for delivery: - If a non-zero 'protocol' argument was specified in the socket() call, is the protocol of the packet the same as the protocol on the socket? - If a local address is bound on the raw socket, is it the same as the destination address on the packet? - If a forieng address is bound on the raw socket, is it the same as the source address on the packet? - If the socket was created by a process in a jail, is the jail IP the same as the destination address on the packet? With these in mind, I'd look for one of two things that might have lead to the symptoms you're seeing: a change in the way your application is written or run such that the address limits on packets received are no longer requested or may now be ambiguous, or a change in the way our system works such that it's no longer implementing the above checks correctly. Ping applications are, btw, supposed to select unique identifiers (typically the pid is used) and then ignore replies with a different identifier, and last I checked ping(8) did that. Could it be that your application is not doing that? Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firewall redirect doesn't work any more...
On Fri, Sep 19, 2008 at 03:38:02PM +0200, Max Laier wrote: I might be wrong, but I don't think we ever supported rdr without net.inet.ip.forwarding enabled. Maybe to a different local address, but even then you'd need net.inet.ip.check_interface=0. Looking at the code, I don't see where IPFW forwarding fails (as it has its own ip_forward() call), though. Ok, I did some more tests. I'm running bridge in there and trying to redirect packets that goes through my bridge to a local daemon. UDP redirect seems to work with PF: rdr on bridge0 proto udp from 10.0.1.1 to 10.0.0.2 port 12345 - 10.0.5.123 port 12345 Between 10.0.1.1 and 10.0.0.2 there is my bridging machine. Now when I call 'nc -u -l 12345' on 10.0.5.123 and call 'nc -u 10.0.0.2 12345' on 10.0.1.1 machine I can receive packets on my nc daemon just fine, I can even send packets back and they are send with source address set to 10.0.0.2 - this is exactly what I'm looking for. Unfortunately it doesn't work for TCP. I see packets beeing redirected to 10.0.5.123, but my local daemon never accepts the connection and nc client keeps resending SYN packets. I also see weird messages in the logs: TCP: [10.0.1.1]:36973 to [10.0.5.123]:12345 tcpflags 0x4RST; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored (Both tcps_badrst and tcps_sc_dropped are increased on every connection attempt.) Any ideas how to make it work with TCP? PS. The same functionality doesn't work at all with ipfw(8) (because of if_bridge(4)?). -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpI0OrLr2V7u.pgp Description: PGP signature
Re: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process.
The following reply was made to PR kern/127528; it has been noted by GNATS. From: Robert Watson [EMAIL PROTECTED] To: Chris Buechler [EMAIL PROTECTED] Cc: freebsd-net@FreeBSD.org, [EMAIL PROTECTED], Bruce M. Simpson [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. Date: Mon, 22 Sep 2008 09:56:45 +0100 (BST) On Sun, 21 Sep 2008, Chris Buechler wrote: This PR is bogus because: ICMP has no concept of datagrams being owned by a process. There is no field in the ICMP protocol which differentiates ICMP sessions on a per-process basis, and this is because ICMP has no concept of sessions -- ICMP messages are directed at IP endpoints. ICMP echo and echo replies do have sessions of sorts, at least unique identifying fields - identifier and sequence number. This was opened by a pfSense maintainer because it's a change in behavior from 6.x releases where this was never an issue, and is something we feel is a regression. Ideally you don't want to be pinging the same host from two different processes, but it's difficult to avoid in some circumstances and it's something that always worked fine prior to FreeBSD 7.0. As far as I'm aware, IP raw sockets have never supported using the ID field to identify sessions or direct packets to specific sockets. This means that a kernel regression in that session semantic is unlikely. However, it could be that you're seeing the impact of another regression relating to other behavior for restricting ICMP received on the raw socket. The kernel code in question is in raw_ip.c:rip_input(), which performs the following checks for each raw IP socket it considers a candidate for delivery: - If a non-zero 'protocol' argument was specified in the socket() call, is the protocol of the packet the same as the protocol on the socket? - If a local address is bound on the raw socket, is it the same as the destination address on the packet? - If a forieng address is bound on the raw socket, is it the same as the source address on the packet? - If the socket was created by a process in a jail, is the jail IP the same as the destination address on the packet? With these in mind, I'd look for one of two things that might have lead to the symptoms you're seeing: a change in the way your application is written or run such that the address limits on packets received are no longer requested or may now be ambiguous, or a change in the way our system works such that it's no longer implementing the above checks correctly. Ping applications are, btw, supposed to select unique identifiers (typically the pid is used) and then ignore replies with a different identifier, and last I checked ping(8) did that. Could it be that your application is not doing that? Robert N M Watson Computer Laboratory University of Cambridge ___ 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]
Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/127528 net[icmp]: icmp socket receives icmp replies not owned by o bin/127192 netrouted(8) removes the secondary alias IP of interface f kern/127145 net[wi]: prism (wi) driver crash at bigger traffic o kern/127102 net[wpi] Intel 3945ABG low throughput o kern/127057 net[udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net[carp] ipv6 does not work on carp interfaces [regressi o kern/126984 net[carp][patch] add carp userland notifications via devc o kern/126945 net[carp] CARP interface destruction with ifconfig destro o kern/126895 net[patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net[vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 netwpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126742 net[panic] kernel panic when sending file via ng_ubt(4) o kern/126714 net[carp] CARP interface renaming makes system no longer o kern/126695 netrtfree messages and network disruption upon use of if_ o kern/126688 net[ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net[ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net[nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net[ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net[fxp] [panic] fxp(4) related kernel panic o kern/126339 net[ipw] ipw driver drops the connection o kern/126214 net[ath] txpower problem with Atheros wifi card o kern/126075 net[in] Network: internet control accesses beyond end of o bin/125922 net[patch] Deadlock in arp(8) o kern/125920 net[arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net[netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net[carp] [bridge] carp stuck in init when using bridge i f kern/125502 net[ral] ifconfig ral0 scan produces no output unless in o kern/125258 net[socket] socket's SO_REUSEADDR option does not work o kern/125239 net[gre] kernel crash when using gre f kern/125195 net[fxp] fxp(4) driver failed to initialize device Intel o kern/125181 net[ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125079 net[ppp] host routes added by ppp with gateway flag (regr o kern/124904 net[fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net[iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net[ieee80211] net80211 discards power-save queue packets o kern/124609 net[ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124341 net[ral] promiscuous mode for wireless device ral0 looses o kern/124160 net[libc] connect(2) function loops indefinitely o kern/124127 net[msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net[ip6] [panic] page fault in nd6_output() o bin/124004 netifconfig(8): Cannot assign both an IP and a MAC addres o kern/123968 net[rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net[vr] [patch] Allow vr interface to handle vlans o kern/123892 net[tap] [patch] No buffer space available o kern/123881 net[tcp] Turning on TCP blackholing causes slow localhost o kern/123796 net[ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 netifconfig(8) doesn't set inet and ether address in one o kern/123617 net[tcp] breaking connection when client downloading file o kern/123603 net[tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net[iwi] iwi periodically disassociates/associates [regre o bin/123465 net[ip6] route(8): route add -inet6 ipv6_addr -interfac o kern/123463 net[ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net[nfe] [hang] ifconfig nfe up causes a hard system lo o kern/123347 net[bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net[nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net[wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net[netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net[bce] Watchdog timeout problems with if_bce o kern/123160 net[ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net
Re: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process.
Chris Buechler wrote: This PR is bogus because: ICMP has no concept of datagrams being owned by a process. There is no field in the ICMP protocol which differentiates ICMP sessions on a per-process basis, and this is because ICMP has no concept of sessions -- ICMP messages are directed at IP endpoints. ICMP echo and echo replies do have sessions of sorts, at least unique identifying fields - identifier and sequence number. These fields do exist in ICMP, and as you point out, they are sometimes used to implement session-like behaviour. Many NAT implementations use them in this way. However there is no way of specifying them in a bind() call -- ICMP can only be received on a raw socket, and raw sockets will not filter these things on behalf of a user process, nor have they ever done to the best of my knowledge. They are not part of the address structures for a raw socket (SOCK_RAW, PF_INET, * or IPPROTO_ICMP). This was opened by a pfSense maintainer because it's a change in behavior from 6.x releases where this was never an issue, and is something we feel is a regression. Robert has replied outlining a few situations where the behaviour might have changed. Raw sockets do support binding laddr/faddr, there is the possibility this could have changed, however there is no notion of processes owning streams of ICMP messages, this has never been part of the ICMP protocol and to think in these terms is misleading. It sounds to me as though the application is relying on a form of filtering which isn't happening, and the way to track this down is to carefully note what, if anything, changed in the expected behaviour between releases. For example, does the application bind() to any given host addresses? This is the only form of filtering, apart from multicast SSM, that raw sockets would support, and SSM ain't in the tree [yet]. thanks BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firewall redirect doesn't work any more...
Hi, Pawel Jakub Dawidek wrote: On Fri, Sep 19, 2008 at 03:38:02PM +0200, Max Laier wrote: I might be wrong, but I don't think we ever supported rdr without net.inet.ip.forwarding enabled. Maybe to a different local address, but even then you'd need net.inet.ip.check_interface=0. Looking at the code, I don't see where IPFW forwarding fails (as it has its own ip_forward() call), though. Ok, I did some more tests. I'm running bridge in there and trying to redirect packets that goes through my bridge to a local daemon. UDP redirect seems to work with PF: rdr on bridge0 proto udp from 10.0.1.1 to 10.0.0.2 port 12345 - 10.0.5.123 port 12345 Between 10.0.1.1 and 10.0.0.2 there is my bridging machine. Now when I call 'nc -u -l 12345' on 10.0.5.123 and call 'nc -u 10.0.0.2 12345' on 10.0.1.1 machine I can receive packets on my nc daemon just fine, I can even send packets back and they are send with source address set to 10.0.0.2 - this is exactly what I'm looking for. Unfortunately it doesn't work for TCP. I see packets beeing redirected to 10.0.5.123, but my local daemon never accepts the connection and nc client keeps resending SYN packets. I also see weird messages in the logs: TCP: [10.0.1.1]:36973 to [10.0.5.123]:12345 tcpflags 0x4RST; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored (Both tcps_badrst and tcps_sc_dropped are increased on every connection attempt.) Any ideas how to make it work with TCP? PS. The same functionality doesn't work at all with ipfw(8) (because of if_bridge(4)?). I use ipfw(8) fwd for tcp with bridge and it works (more or less) fine for me. The network scheme in my setup is: if0 - bridge0 - vlanX lo0 connected jails with private IPs. forwarding enabled, also net.link.bridge.pfil_local_phys=1 to get more control on traffic, but this should not affect the result. I do not use pf since it have problems with ftp+nat. All packets from vlanX to any 80 are redirected to a squid-jail, and there is no problems. (Mostly no, since I have some instability and I get connection timeouts and need to press reload time to time in my browser window. Can't say what is the reason since IIRC the squid version was of the last but no-stable version and it was the first time I've used jail for squid and also jail are behind the natd. I just didn't have a time to dig this problem.) But once again it works. So, could you draw you connections and related firewall rules. And the one you are trying to setup. I will also try to update the machine to the most recent 7 to see if my setup will stop working. Currently machine runs early September checkout. PS. Also check the mac address issue that was discussed here (case where the brdige0 and the first bridge member share the same MAC). rik ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firewall redirect doesn't work any more...
On Mon, Sep 22, 2008 at 05:31:08PM +0400, Roman Kurakin wrote: So, could you draw you connections and related firewall rules. And the one you are trying to setup. I will also try to update the machine to the most recent 7 to see if my setup will stop working. Currently machine runs early September checkout. client (10.0.1.1) - bridge (10.0.5.123) - server (10.0.0.2) ifnet = bridge0 rdr on $ifnet proto tcp from any to any port 12345 - 10.0.5.123 port 12345 rdr on $ifnet proto udp from any to any port 12345 - 10.0.5.123 port 12345 net.inet.ip.forwarding=1 To test my redirection I run: server# nc -u -l 12345 client# nc -u 10.0.0.2 12345 For UDP it works, for TCP it doesn't: server# nc -l 12345 client# nc 10.0.0.2 12345 Although it works even with bridge0 and TCP connections, but when bridge machine is treated as gateway, eg. server# nc -l 12345 client# route add 1.0.0.0/24 10.0.5.123 client# nc 10.0.0.2 12345 PS. Also check the mac address issue that was discussed here (case where the brdige0 and the first bridge member share the same MAC). That's not the case on my test machines. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp4i2ZyKu1Ph.pgp Description: PGP signature
Re: Backporting iwn(4): Success!
On Sun, 21 Sep 2008, Gavin Atkinson wrote: I'm attempting to backport the iwn(4) driver for the Intel 4965 driver from -HEAD to RELENG_7 and am getting stuck with it at one particular point: WPA authentication times out. As a followup to this, with a bit of help from Sam Leffler, I've now succeeded in getting this working. If you're interested in using this driver under RELENG_7 plese see my post to freebsd-stable@: http://docs.FreeBSD.org/cgi/mid.cgi?1222090773.43647.16.camel Gavin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firewall redirect doesn't work any more...
Pawel Jakub Dawidek wrote: On Mon, Sep 22, 2008 at 05:31:08PM +0400, Roman Kurakin wrote: So, could you draw you connections and related firewall rules. And the one you are trying to setup. I will also try to update the machine to the most recent 7 to see if my setup will stop working. Currently machine runs early September checkout. client (10.0.1.1) - bridge (10.0.5.123) - server (10.0.0.2) ifnet = bridge0 rdr on $ifnet proto tcp from any to any port 12345 - 10.0.5.123 port 12345 rdr on $ifnet proto udp from any to any port 12345 - 10.0.5.123 port 12345 Try also to play with stateful switches for pf. By the way do you have any global that affects defaults? net.inet.ip.forwarding=1 To test my redirection I run: server# nc -u -l 12345 client# nc -u 10.0.0.2 12345 For UDP it works, for TCP it doesn't: server# nc -l 12345 client# nc 10.0.0.2 12345 Although it works even with bridge0 and TCP connections, but when bridge machine is treated as gateway, eg. server# nc -l 12345 client# route add 1.0.0.0/24 10.0.5.123 client# nc 10.0.0.2 12345 And what about ipfw variant? rik PS. Also check the mac address issue that was discussed here (case where the brdige0 and the first bridge member share the same MAC). That's not the case on my test machines. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
bridged tap interfaces with stp
Hi! I am playing with bridge(4) stp feature. there are 2 boxes with 7.0-RELEASE-p4. rt1rt2 ___ ___ || || | |tap1| |tap1| | | | | | | |tap2|-|tap2| | |___| |___| rt1 connected to rt2 with 2 openvpn L2 links (tap). tap1 bridged with tap2 on both routers. rt1# ifconfig bridge0 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 56:8d:35:75:ee:3f inet 3.3.3.1 netmask 0xff00 broadcast 3.3.3.255 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: tap2 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP member: tap1 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP rt2# ifconfig bridge0 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 3a:af:9d:0f:c1:b9 inet 3.3.3.2 netmask 0xff00 broadcast 3.3.3.255 id 00:00:00:00:00:00 priority 16384 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 16384 ifcost 0 port 0 member: tap2 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP member: tap1 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP rt1# ping 3.3.3.2 PING 3.3.3.2 (3.3.3.2): 56 data bytes 64 bytes from 3.3.3.2: icmp_seq=0 ttl=64 time=8.144 ms 64 bytes from 3.3.3.2: icmp_seq=1 ttl=64 time=4.313 ms 64 bytes from 3.3.3.2: icmp_seq=2 ttl=64 time=4.421 ms ... all works while broadcast Then I'd try to enable stp on bridge0 interfaces for automatic disable one of redundant links (tap1/tap2). rt1# ifconfig bridge0 stp tap1 stp tap2 rt1# ifconfig bridge0 bridge0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 56:8d:35:75:ee:3f inet 3.3.3.1 netmask 0xff00 broadcast 3.3.3.255 id 00:1c:c0:39:d6:b9 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:1c:c0:39:d6:b9 priority 32768 ifcost 0 port 0 member: tap2 flags=147LEARNING,DISCOVER,STP,AUTOEDGE,AUTOPTP port 12 priority 128 path cost 200 proto rstp role disabled state discarding member: tap1 flags=147LEARNING,DISCOVER,STP,AUTOEDGE,AUTOPTP port 16 priority 128 path cost 200 proto rstp role disabled state discarding rt2# ifconfig bridge0 stp tap1 stp tap2 rt2# ifconfig bridge0 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 3a:af:9d:0f:c1:b9 inet 3.3.3.2 netmask 0xff00 broadcast 3.3.3.255 id 00:1c:c0:39:d6:ad priority 16384 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:1c:c0:39:d6:ad priority 16384 ifcost 0 port 0 member: tap2 flags=147LEARNING,DISCOVER,STP,AUTOEDGE,AUTOPTP port 9 priority 128 path cost 200 proto rstp role disabled state discarding member: tap1 flags=147LEARNING,DISCOVER,STP,AUTOEDGE,AUTOPTP port 8 priority 128 path cost 200 proto rstp role disabled state discarding But when stp is enabled, it blocks all bridge members, and bridge stop working. May be I am misunderstand something with stp? At all it is possible to use bridge(4) stp with tap(4)? Even when bridge0 on both router has only 1 member, ports stay in disabled state. rt1# ifconfig bridge0 deletem tap1 deletem tap2 rt1# ifconfig bridge0 bridge0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 56:8d:35:75:ee:3f inet 3.3.3.1 netmask 0xff00 broadcast 3.3.3.255 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 rt2# ifconfig bridge0 deletem tap1 deletem tap2 rt2# ifconfig bridge0 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 3a:af:9d:0f:c1:b9 inet 3.3.3.2 netmask 0xff00 broadcast 3.3.3.255 id 00:00:00:00:00:00 priority 16384 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 16384 ifcost 0 port 0 rt1# ifconfig bridge0 addm tap1 stp tap1 rt1# ifconfig bridge0 bridge0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 56:8d:35:75:ee:3f inet 3.3.3.1 netmask 0xff00 broadcast 3.3.3.255 id 00:1c:c0:39:d6:b9 priority 32768 hellotime
Re: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process.
Synopsis: [icmp]: icmp socket receives icmp replies not owned by the process. State-Changed-From-To: open-feedback State-Changed-By: rwatson State-Changed-When: Mon Sep 22 14:22:16 UTC 2008 State-Changed-Why: Request feedback based on correspondence to date -- the delivery of ICMP messages to multiple raw sockets is historical behavior from the original BSD network stack, and not considered a bug. However, clearly something has changed in the software configuration leading to the reported symptoms, and a FreeBSD kernel bug is not precluded as perhaps some other portion of raw IP socket input processing has changed and/or been broken. Please let us know what further investigation reveals about the source of the problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=127528 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firewall redirect doesn't work any more...
On Mon, Sep 22, 2008 at 06:11:35PM +0400, Roman Kurakin wrote: Pawel Jakub Dawidek wrote: On Mon, Sep 22, 2008 at 05:31:08PM +0400, Roman Kurakin wrote: So, could you draw you connections and related firewall rules. And the one you are trying to setup. I will also try to update the machine to the most recent 7 to see if my setup will stop working. Currently machine runs early September checkout. client (10.0.1.1) - bridge (10.0.5.123) - server (10.0.0.2) ifnet = bridge0 rdr on $ifnet proto tcp from any to any port 12345 - 10.0.5.123 port 12345 rdr on $ifnet proto udp from any to any port 12345 - 10.0.5.123 port 12345 Try also to play with stateful switches for pf. [...] Adding the following made even UDP non-working: pass in on $ifnet proto udp from any to any keep state For TCP there was no difference. [...] By the way do you have any global that affects defaults? Besides net.inet.ip.forwarding=1, no, although I tried various settings for net.link.bridge.*. Although it works even with bridge0 and TCP connections, but when bridge machine is treated as gateway, eg. server# nc -l 12345 client# route add 1.0.0.0/24 10.0.5.123 client# nc 10.0.0.2 12345 And what about ipfw variant? For the first (bridge) case ipfw didn't work at all. No packets were redirected. I haven't tried for the gateway case, because pf works there. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpfnz3mdpYRi.pgp Description: PGP signature
Re: bridged tap interfaces with stp
On Mon, Sep 22, 2008 at 05:00:59PM +0300, Sergey Listopad wrote: Hi! I am playing with bridge(4) stp feature. there are 2 boxes with 7.0-RELEASE-p4. rt1rt2 ___ ___ || || | |tap1| |tap1| | | | | | | |tap2|-|tap2| | |___| |___| rt1 connected to rt2 with 2 openvpn L2 links (tap). tap1 bridged with tap2 on both routers. rt1# ifconfig bridge0 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 56:8d:35:75:ee:3f inet 3.3.3.1 netmask 0xff00 broadcast 3.3.3.255 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: tap2 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP member: tap1 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP rt2# ifconfig bridge0 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 3a:af:9d:0f:c1:b9 inet 3.3.3.2 netmask 0xff00 broadcast 3.3.3.255 id 00:00:00:00:00:00 priority 16384 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 16384 ifcost 0 port 0 member: tap2 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP member: tap1 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP rt1# ping 3.3.3.2 PING 3.3.3.2 (3.3.3.2): 56 data bytes 64 bytes from 3.3.3.2: icmp_seq=0 ttl=64 time=8.144 ms 64 bytes from 3.3.3.2: icmp_seq=1 ttl=64 time=4.313 ms 64 bytes from 3.3.3.2: icmp_seq=2 ttl=64 time=4.421 ms ... all works while broadcast Then I'd try to enable stp on bridge0 interfaces for automatic disable one of redundant links (tap1/tap2). rt1# ifconfig bridge0 stp tap1 stp tap2 rt1# ifconfig bridge0 bridge0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 56:8d:35:75:ee:3f inet 3.3.3.1 netmask 0xff00 broadcast 3.3.3.255 id 00:1c:c0:39:d6:b9 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:1c:c0:39:d6:b9 priority 32768 ifcost 0 port 0 member: tap2 flags=147LEARNING,DISCOVER,STP,AUTOEDGE,AUTOPTP port 12 priority 128 path cost 200 proto rstp role disabled state discarding member: tap1 flags=147LEARNING,DISCOVER,STP,AUTOEDGE,AUTOPTP port 16 priority 128 path cost 200 proto rstp role disabled state discarding rt2# ifconfig bridge0 stp tap1 stp tap2 rt2# ifconfig bridge0 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 3a:af:9d:0f:c1:b9 inet 3.3.3.2 netmask 0xff00 broadcast 3.3.3.255 id 00:1c:c0:39:d6:ad priority 16384 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:1c:c0:39:d6:ad priority 16384 ifcost 0 port 0 member: tap2 flags=147LEARNING,DISCOVER,STP,AUTOEDGE,AUTOPTP port 9 priority 128 path cost 200 proto rstp role disabled state discarding member: tap1 flags=147LEARNING,DISCOVER,STP,AUTOEDGE,AUTOPTP port 8 priority 128 path cost 200 proto rstp role disabled state discarding But when stp is enabled, it blocks all bridge members, and bridge stop working. May be I am misunderstand something with stp? At all it is possible to use bridge(4) stp with tap(4)? This is because tap(4) does not have a media attachment, the spanning tree code uses this to check if there is a link and obtain the duplex (see bstp_ifupdstatus). Im not sure what the answer is, maybe ignore this for pseudo interfaces. Andrew ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firewall redirect doesn't work any more...
Pawel Jakub Dawidek wrote: And what about ipfw variant? For the first (bridge) case ipfw didn't work at all. No packets were redirected. I haven't tried for the gateway case, because pf works there. ipfw forwarding is disabled for bridge and L2 cases. (I think the man page says so.) At Ironport we added some small patche sto allow this to occur. it is relatively simple.. (less than 10 lines) When ipfw returns that a packet to the bridge, that has been marked as 'redirected', then you accept it to the IP stack as if it was addressed to the local machine. You then make sure that in L3 ipfe processing, you hit the same fwd rule, and this time it is sent to the right place. It does require that ipfw see the packet twice, but it works. A further hack would be to add code in the IP stack so that a packet tagged as redirected from the bridge would skip ipfw in the IP stack and go direct to the redirection. (but that may open security issues). ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firewall redirect doesn't work any more...
On Monday 22 September 2008 12:22:09 Pawel Jakub Dawidek wrote: On Fri, Sep 19, 2008 at 03:38:02PM +0200, Max Laier wrote: I might be wrong, but I don't think we ever supported rdr without net.inet.ip.forwarding enabled. Maybe to a different local address, but even then you'd need net.inet.ip.check_interface=0. Looking at the code, I don't see where IPFW forwarding fails (as it has its own ip_forward() call), though. Ok, I did some more tests. I'm running bridge in there and trying to redirect packets that goes through my bridge to a local daemon. UDP redirect seems to work with PF: rdr on bridge0 proto udp from 10.0.1.1 to 10.0.0.2 port 12345 - 10.0.5.123 port 12345 Between 10.0.1.1 and 10.0.0.2 there is my bridging machine. Now when I call 'nc -u -l 12345' on 10.0.5.123 and call 'nc -u 10.0.0.2 12345' on 10.0.1.1 machine I can receive packets on my nc daemon just fine, I can even send packets back and they are send with source address set to 10.0.0.2 - this is exactly what I'm looking for. Unfortunately it doesn't work for TCP. I see packets beeing redirected to 10.0.5.123, but my local daemon never accepts the connection and nc client keeps resending SYN packets. I also see weird messages in the logs: TCP: [10.0.1.1]:36973 to [10.0.5.123]:12345 tcpflags 0x4RST; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored (Both tcps_badrst and tcps_sc_dropped are increased on every connection attempt.) Any ideas how to make it work with TCP? PS. The same functionality doesn't work at all with ipfw(8) (because of if_bridge(4)?). The problem is that the packet is still subject to bridge's L2 processing and thus will make it's way to the original MAC receiver that will bark on it. What you could try is a pf route-to rule to lo0 and 127.0.0.1 and then rdr on lo0. In contrast to rdr, a route-to rule will consume the packet and reinject it into the IP-processing path. This way it won't be forwarded by the bridge and there should not be problems. That being said, it's rather difficult to write firewall rules for a bridge as there is no clear concept of direction (in/out). In scenarios like this I usually suggest filtering on the member interfaces only: net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 0 -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [X-POST] Anyone porting NetworkManager to FreeBSD ?
On Mon, 2008-09-22 at 11:22 +0530, Ashish Shukla आशीष शुक्ल wrote: Joe Marcus Clarke writes: On Sun, 2008-09-21 at 03:26 +0530, Ashish Shukla आशीष शुक्ल wrote: Hi all, Is there anyone, who is porting NetworkManager[1] to FreeBSD ? If yes, I would like to be a tester or contributor to the effort. It's been on our ideas list for a while, and I think someone mentioned they were working on it a few months ago (check the archives). I held a desktop discussion at the last BSDCan, and Kris Moore of PC-BSD suggested it may be easier to port their network manager (http://svn.pcbsd.org/browser/pcbsd/trunk/NetworkManager) from KDE to GTK+/GNOME In the meantime, I did a GNOME PBI for PC-BSD, and added hooks to make use of some of PC-BSD's admin tools. The result was positive. However, it would be great to have working GTK+/GNOME native tools. Thanks for the reply. But, that looks like a static network configuration tool. Sorry, wrong link. There are a few network admin tools in PC-BSD (including a task tray application). Here is their wireless config app: http://svn.pcbsd.org/browser/pcbsd/trunk/wificonfi . The advantage of using the PC-BSD code is that the FreeBSD internal stuff is done already. That could could be used as a model for creating a GTK+/GNOME frontend. On the other hand, porting NM would require adapting it to your net80211 stack. Joe Ashish -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
