Re: MAC locking and filtering in FreeBSD
On (13/05/2009 13:29), Brett Glass wrote: > At 01:07 PM 5/13/2009, Andrew Thompson wrote: > > >This has been implemented as part of Gleb Kurtsov's 2008 SoC project. > >http://wiki.freebsd.org/GlebKurtsov/Improving_layer2_filtering > > > >It has not been committed yet but I beleieve is ready to go in, you can > >find the code on the svn branch > >http://svn.freebsd.org/viewvc/base/projects/l2filter/ > > How does one generate a diff between this code and, say, > 7.1-RELEASE or 7.2-RELEASE so that I can try it as a patch? The GUI > doesn't seem to be capable of doing this (or it may be that I just > don't see how). I'd suggest you using latest patchs from http://blogs.freebsdish.org/gleb/2009/03/24/layer2-dummynet/ projects svn repository is quiet outdated, and I was going to make patch against 7.2 on this weekend (will blog about it) > > --Brett Glass > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: MAC locking and filtering in FreeBSD
Hi Brett, I think what you are looking for is called captive portal. You can look at pfsense - http://doc.pfsense.org/index.php/Category:Captive_Portal which comes with such solution into it. On May 14, 2009, at 1:29 AM, Brett Glass wrote: At 03:38 PM 5/13/2009, Christian Brueffer wrote: Sounds like wlan_acl(4) may be of interest to you. Unfortunately, wlan_acl(4) is only useful if one wants to ban users from the network, which these venues will rarely want to do except to block an abuser. Rather, they'll want the equipment to recognize MAC addresses and grant different degrees of access to them. For example, a user might be trapped in a "walled garden" until agreeing to an acceptable use policy, and then redirected -- but only once -- to a specific Web page, such as the hotel chain's reservation page. --Brett Glass -- 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 "freebsd-net-unsubscr...@freebsd.org"
Re: MAC locking and filtering in FreeBSD
On Thu, 14 May 2009, Brett Glass wrote: > At 12:17 AM 5/14/2009, Ian Smith wrote: > > >You can use fixed leases with MAC specified in dhcp for that, > > This lets you assign specific addresses to machines with specific MAC > addresses. But it doesn't inhibit MAC address "cloning," and the DHCP > server cannot force a machine to use a specific IP or stop it from > using one that was not assigned to it. You can have it only issue a lease for a given IP to a machine with the correct MAC, and issue no leases to any other machines; at least, that works for us. Of course that can't prevent someone who a) knows the IP address to MAC mapping, and b) can spoof the MAC address. I don't know what could prevent that, but it's hardly the common scenario. Then have ipfw refuse traffic from addresses other than those allowed. > >Re ipfw(8), I'm not clear on what your problem is: the section PACKET > >FLOW shows clearly how to distinguish layer 2 from layer 3 traffic. > > The problem is that you cannot test both the MAC address and the IP > address in the same rule -- at least in the current implementation. Assuming you have net.link.ether.ipfw=1 to get layer 2 packets, and are separating your layer 2 packets for testing as shown under PACKET FLOW, can you show us the rule to do just that, that isn't working right? > >Your 'vice versa' here isn't correct; you can select by layer 3 criteria > >on packets from ether_demux, > > The docs say that you can't. Please point out where ipfw(8) says that? cheers, Ian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Weird dhclient behavior after today's rebuild
On Thursday 14 May 2009 07:32:22 Li, Qing wrote: > I have committed the patch, please update your source and > give it a try. > > Thanks, > > -- Qing > After fresh csup and rebuild it works again. I suppose your fix wents into sys/netinet/in.c, as I did not see anything else network related in csup's output... Thanks for quick fix. Milan > -Original Message- > From: owner-freebsd-...@freebsd.org on behalf of Milan Obuch > Sent: Wed 5/13/2009 10:03 PM > To: freebsd-net@freebsd.org > Subject: Weird dhclient behavior after today's rebuild > > Hi, > > I did full system rebuild from freshly csup'ped sources. Everything went > smooth as usual, but after reboot network card did not get configured via > DHCP. There were four lines logged on console/in syslog: > > dhclient[822]: re0: not found > dhclient[822]: exiting > dhclient[823]: connection closed > dhclient[823]: exiting > > I did some tests, disabled automatic dhclient invocation in rc.conf. > > Then, after connecting cable, ifconfig re0 show status active, netstat -rnf > inet shows only loopback route (128.0.0.1 on lo0). Manually starting > dhclient re0: > > ifconfig: ioctl (SIOCAIFADDR): File exists > re0: not found > exiting > [ snip ] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/132984: [netgraph] swi1: net 100% cpu usage
The following reply was made to PR kern/132984; it has been noted by GNATS. From: Sergey Pronin To: bug-follo...@freebsd.org, v...@prokk.net Cc: Subject: Re: kern/132984: [netgraph] swi1: net 100% cpu usage Date: Thu, 14 May 2009 18:39:35 +0400 --000e0cd311a2045e870469e04ca6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This bug is still urgent for me. Was it solved? --000e0cd311a2045e870469e04ca6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This bug is still urgent for me. Was it solved? --000e0cd311a2045e870469e04ca6-- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/134079: [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8.0)
The following reply was made to PR kern/134079; it has been noted by GNATS. From: Stacey Son To: bug-follo...@freebsd.org, g.zhengm...@gmail.com Cc: Subject: Re: kern/134079: [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8.0) Date: Thu, 14 May 2009 13:18:35 -0500 I have the same, exact problem with FreeBSD-Current running on VMWare Fusion (64-bit, 2 virtual procs, 4096MB Memory allocation, Mac Pro host). Running 7.2 on this same configuration there is no problem with the e1000 (if_em) driver. Upgrading to -current I get the following error (in dmesg): em0: Invalid MAC address device_attach:em0 attach returned 5 My work around is to edit the "vmx" config file on the host for the virtual image and change: ethernet0.virtualDev="e1000" to: ethernet0.virtualDev="vlance" so the virtual machine emulates an AMD Lance instead. -stacey. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
IPv6 fragmentation weirdness
I have recently noticed problems with data transfers via IPv6. Attempt to fetch files from dome sites was hanging as soon as the data started to flow. Felt like an MTU issue, so I tried sending various sizes of ICMP echo (ping) packets and discovered that I could not send a packet of over 1280 bytes. (ping6 -s 1232) If I disabled kernel fragmentation (-m), I could use packets up to the MTU of my interface (1500 bytes). The path is entirely native IPv6. No tunnels. All should allow full 1500 byte packets. I then captured the ICMP and discovered that the kernel was fragmenting all of them! Worse, the fragment was sent out before the ICMP! What the heck is going on! Thread synchronization? When I captured the packets (via tcpdump -s0 -w file host ftp.funet.fi), the first things captured is an IPv6 fragment of 72 bytes. 3 microseconds later, I get the ICMP6 packet of 1294 bytes. This pattern is consistent over repeated packets. This was with -s 1234 for a total ICMPv6 size of 1282. First, why is the kernel fragmenting this at all as it fits in the interface MTU? Second, why the heck is the fragment going out first? This should be OK, but I suspect many firewalls (which are often not happy with fragments) are not likely to pass a fragment which precedes the initial frame. Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is something in the path that is blocking my traffic, so others may not see this, but I think the root issues is the kernel fragmenting packets way below MTU size. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 fragmentation weirdness
> First, why is the kernel fragmenting this at all as it fits in the > interface MTU? Good question, I definitely disagree with this behavior and would say that it breaks POLA. But it's documented (see the ping6 -m option). > Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is > something in the path that is blocking my traffic, so others may not see > this, but I think the root issues is the kernel fragmenting packets way > below MTU size. I just picked up a copy of the 7.2 bootonly ISO image using IPv6. Slow but usable. My path (from Oslo, Norway) is: sth...@lab1% traceroute6 ftp.funet.fi traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:8c0:8b00:1::2, 64 hops max, 12 byte packets 1 ge-0-0-9-515.br1.fn3.no.catchbone.net 0.254 ms 4.917 ms 0.203 ms 2 c10G-ge-5-1-0.cr2.osls.no.catchbone.net 0.485 ms 0.408 ms 0.399 ms 3 c10G-xe-4-1-0.br1.osls.no.catchbone.net 0.364 ms 0.351 ms 0.361 ms 4 2001:2000:3083:6::1 9.006 ms 8.848 ms 8.966 ms 5 s-ipv6-b1-link.ipv6.telia.net 19.481 ms 19.590 ms 19.412 ms 6 2001:2000:3080:d::2 110.907 ms 109.056 ms 119.495 ms 7 helsinki0-rtr.funet.fi 116.305 ms 123.534 ms 119.472 ms 8 csc0-x-helsinki0.ipv6.funet.fi 118.873 ms 117.439 ms 116.054 ms 9 ftp.funet.fi 115.777 ms 116.087 ms 117.735 ms Note that the IPv6 transit from Telia is tunnelled, and the RTT is awful compared to IPv4 (IPv4 RTT to ftp.funet.fi from the same box is around 17 ms). Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 fragmentation weirdness
> Date: Fri, 15 May 2009 00:09:02 +0200 (CEST) > From: sth...@nethelp.no > > > First, why is the kernel fragmenting this at all as it fits in the > > interface MTU? > > Good question, I definitely disagree with this behavior and would say > that it breaks POLA. But it's documented (see the ping6 -m option). > > > Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is > > something in the path that is blocking my traffic, so others may not see > > this, but I think the root issues is the kernel fragmenting packets way > > below MTU size. > > I just picked up a copy of the 7.2 bootonly ISO image using IPv6. Slow > but usable. My path (from Oslo, Norway) is: > > sth...@lab1% traceroute6 ftp.funet.fi > traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:8c0:8b00:1::2, 64 > hops max, 12 byte packets > 1 ge-0-0-9-515.br1.fn3.no.catchbone.net 0.254 ms 4.917 ms 0.203 ms > 2 c10G-ge-5-1-0.cr2.osls.no.catchbone.net 0.485 ms 0.408 ms 0.399 ms > 3 c10G-xe-4-1-0.br1.osls.no.catchbone.net 0.364 ms 0.351 ms 0.361 ms > 4 2001:2000:3083:6::1 9.006 ms 8.848 ms 8.966 ms > 5 s-ipv6-b1-link.ipv6.telia.net 19.481 ms 19.590 ms 19.412 ms > 6 2001:2000:3080:d::2 110.907 ms 109.056 ms 119.495 ms > 7 helsinki0-rtr.funet.fi 116.305 ms 123.534 ms 119.472 ms > 8 csc0-x-helsinki0.ipv6.funet.fi 118.873 ms 117.439 ms 116.054 ms > 9 ftp.funet.fi 115.777 ms 116.087 ms 117.735 ms > > Note that the IPv6 transit from Telia is tunnelled, and the RTT is awful > compared to IPv4 (IPv4 RTT to ftp.funet.fi from the same box is around > 17 ms). > > Steinar Haug, Nethelp consulting, sth...@nethelp.no > Thanks, Steinar. I just re-read the man page and I had misunderstood what it was saying. That still leave me baffled as to what is happening. My path is, as would be expected, very different. traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:400:0:40::200:101, 64 hops max, 12 byte packets 1 esnet.rt1.ams.nl.geant2.net (2001:798:29:10aa::9) 83.998 ms 115.099 ms 85.969 ms 2 so-7-0-0.rt2.cop.dk.geant2.net (2001:798:cc:1501:2201::1) 101.692 ms 96.955 ms 96.868 ms 3 nordunet-gw.rt2.cop.dk.geant2.net (2001:798:15:10aa::2) 179.931 ms 205.407 ms 195.268 ms 4 dk-uni.nordu.net (2001:948:0:f055::2) 210.468 ms se-fre.nordu.net (2001:948:0:f03f::1) 187.479 ms dk-uni.nordu.net (2001:948:0:f055::2) 190.578 ms 5 se-tug.nordu.net (2001:948:0:f049::2) 188.170 ms 213.538 ms se-tug.nordu.net (2001:948:0:f056::1) 183.273 ms 6 helsinki0-rtr.funet.fi (2001:948:0:f035::2) 188.114 ms 189.214 ms 192.192 ms 7 csc0-x-helsinki0.ipv6.funet.fi (2001:708:0:f000::1:2) 186.166 ms 190.181 ms 186.669 ms 8 ftp.funet.fi (2001:708:10:9::20:1) 186.251 ms 198.591 ms 205.987 ms This is exactly the same as my IPv4 path. Something along this path is silently refusing to pass a packet at the start of the transfer and that screams MTU. If I ping from a Juniper router, I can get 1482 byte packets through, so I suspect that there is a tunnel somewhere. But FreeBSD boxes die at the lower limit. Does the kernel fragmentation only affect ICMP or are TCP packet also fragmented at 1280 bytes? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 fragmentation weirdness
On Thu, 14 May 2009, Kevin Oberman wrote: Hi, Date: Fri, 15 May 2009 00:09:02 +0200 (CEST) From: sth...@nethelp.no First, why is the kernel fragmenting this at all as it fits in the interface MTU? Good question, I definitely disagree with this behavior and would say that it breaks POLA. But it's documented (see the ping6 -m option). Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is something in the path that is blocking my traffic, so others may not see this, but I think the root issues is the kernel fragmenting packets way below MTU size. I just picked up a copy of the 7.2 bootonly ISO image using IPv6. Slow but usable. My path (from Oslo, Norway) is: sth...@lab1% traceroute6 ftp.funet.fi traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:8c0:8b00:1::2, 64 hops max, 12 byte packets 1 ge-0-0-9-515.br1.fn3.no.catchbone.net 0.254 ms 4.917 ms 0.203 ms 2 c10G-ge-5-1-0.cr2.osls.no.catchbone.net 0.485 ms 0.408 ms 0.399 ms 3 c10G-xe-4-1-0.br1.osls.no.catchbone.net 0.364 ms 0.351 ms 0.361 ms 4 2001:2000:3083:6::1 9.006 ms 8.848 ms 8.966 ms 5 s-ipv6-b1-link.ipv6.telia.net 19.481 ms 19.590 ms 19.412 ms 6 2001:2000:3080:d::2 110.907 ms 109.056 ms 119.495 ms 7 helsinki0-rtr.funet.fi 116.305 ms 123.534 ms 119.472 ms 8 csc0-x-helsinki0.ipv6.funet.fi 118.873 ms 117.439 ms 116.054 ms 9 ftp.funet.fi 115.777 ms 116.087 ms 117.735 ms Note that the IPv6 transit from Telia is tunnelled, and the RTT is awful compared to IPv4 (IPv4 RTT to ftp.funet.fi from the same box is around 17 ms). Steinar Haug, Nethelp consulting, sth...@nethelp.no Thanks, Steinar. I just re-read the man page and I had misunderstood what it was saying. That still leave me baffled as to what is happening. My path is, as would be expected, very different. traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:400:0:40::200:101, 64 hops max, 12 byte packets 1 esnet.rt1.ams.nl.geant2.net (2001:798:29:10aa::9) 83.998 ms 115.099 ms 85.969 ms 2 so-7-0-0.rt2.cop.dk.geant2.net (2001:798:cc:1501:2201::1) 101.692 ms 96.955 ms 96.868 ms 3 nordunet-gw.rt2.cop.dk.geant2.net (2001:798:15:10aa::2) 179.931 ms 205.407 ms 195.268 ms 4 dk-uni.nordu.net (2001:948:0:f055::2) 210.468 ms se-fre.nordu.net (2001:948:0:f03f::1) 187.479 ms dk-uni.nordu.net (2001:948:0:f055::2) 190.578 ms 5 se-tug.nordu.net (2001:948:0:f049::2) 188.170 ms 213.538 ms se-tug.nordu.net (2001:948:0:f056::1) 183.273 ms 6 helsinki0-rtr.funet.fi (2001:948:0:f035::2) 188.114 ms 189.214 ms 192.192 ms 7 csc0-x-helsinki0.ipv6.funet.fi (2001:708:0:f000::1:2) 186.166 ms 190.181 ms 186.669 ms 8 ftp.funet.fi (2001:708:10:9::20:1) 186.251 ms 198.591 ms 205.987 ms This is exactly the same as my IPv4 path. Something along this path is silently refusing to pass a packet at the start of the transfer and that screams MTU. If I ping from a Juniper router, I can get 1482 byte packets through, so I suspect that there is a tunnel somewhere. But FreeBSD boxes die at the lower limit. Does the kernel fragmentation only affect ICMP or are TCP packet also fragmented at 1280 bytes? WRT to TCP you may also want to check the hostcache: sysctl net.inet.tcp.hostcache.list -- Bjoern A. Zeeb The greatest risk is not taking one. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/134531: [route] [panic] kernel crash related to routes/zebra
Old Synopsis: kernel crash related to routes/zebra New Synopsis: [route] [panic] kernel crash related to routes/zebra Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 14 23:05:22 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134531 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
