Re: forwarding didn't work if wlan0 is member of a bridge
On Dec 23, 2015 2:32 AM, "Olivier Cochard-Labbé" wrote: > Hi, > > If wlan0 interface is member of a bridge, FreeBSD didn't reach to > forward-back packets to wireless client > > My setup is this one: > > internet gateway <--> [net0] fbsd router [net1 + wifi-hostap in bridge0] > <--> wireless client > > and the problem description: > - wireless clients didn't receive any packet back: the fbsd-router blocks > answers because it thinks wireless clients are "unreachable". > - But wireless clients can reach all IP of the fbsd-router hitself without > problem, and fbsd-router can ping them too. > - Ethernet clients connected to the same bridge0 didn't have problem > > A tcpdump on the outgoing interface shows the fbsd-router correctly > receiving/NATing/forwarding the wireless-client packet (10.239.142.104 > natted to 192.168.100.70) toward the Internet-gateway (192.168.100.254), > but once received the response from the internet-gateway it is not able to > reach the wireless-client (unreachable): > [fbsd-router]~> sudo tcpdump -pni net0 icmp > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on net0, link-type EN10MB (Ethernet), capture size 262144 bytes > 07:35:24.869560 IP 192.168.100.70 > 192.168.100.254: ICMP echo request, id > 1, seq 375, length 40 > 07:35:24.869772 IP 192.168.100.254 > 192.168.100.70: ICMP echo reply, id > 1, > seq 375, length 40 > 07:35:24.870314 IP 192.168.100.70 > 192.168.100.254: ICMP host > 10.239.142.104 unreachable, length 36 > > But directly from the fbsd-router, there is no problem for reaching the > wireless-client: > [fbsd-router]~> ping wireless-client > PING 10.239.142.104 (10.239.142.104): 56 data bytes > 64 bytes from 10.239.142.104: icmp_seq=0 ttl=128 time=2.633 ms > 64 bytes from 10.239.142.104: icmp_seq=1 ttl=128 time=1.614 ms > > I'm using a bridge because I need to use only one subnet for all my clients > (ethernet and wifi): > [fbsd-router]~> ifconfig bridge0 > bridge0: flags=8843 metric 0 mtu > 1500 > ether 02:82:9f:45:81:00 > inet 10.239.142.126 netmask 0xffe0 broadcast 10.239.142.127 > nd6 options=49 > groups: bridge > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: wlan0 flags=143 > ifmaxaddr 0 port 6 priority 128 path cost 3 > member: net1 flags=143 > ifmaxaddr 0 port 2 priority 128 path cost 55 > > And this "unreacheable" problem is related to the bridge, if I remove the > wlan0 from the bridge, there is no more problem. > > What problem can cause FreeBSD to answer back "unreachable" when wlan0 is > member of a bridge ? > > Head versions tested: r290522, r291362, r292613. > > Thanks, > ___ > freebsd-wirel...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org > " > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: forwarding didn't work if wlan0 is member of a bridge
On Tue, Jan 12, 2016 at 9:52 PM, Alexander V. Chernikov < melif...@freebsd.org> wrote: > > Could you show 'netstat -rn' output when one of bridge members is down? > Btw, I tried to reproduce it today (but, with ix0 instead of wlan0) and I > wasn't able to trigger the problem. > > Sure, here some output with the re1 (member of bridge) unplugged: root@ fbsd-router :~ # ifconfig bridge0 bridge0: flags=8843 metric 0 mtu 1500 ether 02:6b:c0:de:b8:00 inet 1.1.1.1 netmask 0xff00 broadcast 1.1.1.255 nd6 options=9 groups: bridge id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: wlan0 flags=143 ifmaxaddr 0 port 5 priority 128 path cost 3 member: re1 flags=143 ifmaxaddr 0 port 2 priority 128 path cost 55 root@ fbsd-router :~ # ifconfig re1 re1: flags=8943 metric 0 mtu 1500 options=82099 ether 00:0d:b9:3c:ae:25 nd6 options=29 media: Ethernet autoselect (none) status: no carrier root@ fbsd-router :~ # netstat -r 4 n Routing tables Internet: DestinationGatewayFlags Netif Expire 1.0.0.0/24 link#1 U re0 1.0.0.1link#1 UHS lo0 1.1.1.0/24 link#6 U bridge0 1.1.1.1link#6 UHS lo0 127.0.0.1 link#4 UH lo0 During this "one-member-unplugged", the freebsd-router can still ping each hosts on different connected interface, it just "refuse" to forward between its interfaces: root@fbsd-router:~ # ping 1.1.1.2 (the wireless client connected to wlan0, member of the bridge0 interface) PING 1.1.1.2 (1.1.1.2): 56 data bytes 64 bytes from 1.1.1.2: icmp_seq=0 ttl=64 time=4.600 ms 64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=5.878 ms ^C --- 1.1.1.2 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 4.600/5.239/5.878/0.639 ms root@fbsd-router:~ # ping 1.0.0.2 (an host on the LAN0) PING 1.0.0.2 (1.0.0.2): 56 data bytes 64 bytes from 1.0.0.2: icmp_seq=0 ttl=64 time=0.282 ms 64 bytes from 1.0.0.2: icmp_seq=1 ttl=64 time=0.280 ms ^C --- 1.0.0.2 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.280/0.281/0.282/0.001 ms root@fbsd-router:~ # arp -na ? (1.1.1.1) at 02:6b:c0:de:b8:00 on bridge0 permanent [bridge] ? (1.1.1.2) at 00:c0:ca:7e:8b:fe on bridge0 expires in 1055 seconds [bridge] ? (1.0.0.1) at 00:0d:b9:3c:ae:24 on re0 permanent [ethernet] ? (1.0.0.2) at 0c:c4:7a:6b:a6:d3 on re0 expires in 1106 seconds [ethernet] And the wireless client (1.1.1.2) can still ping the fbsd-router bridge interface (1.1.1.1) too (for answering to the Adrian question). Now I replug re1: root@fbsd-router:~ # ifconfig re1 re1: flags=8943 metric 0 mtu 1500 options=82099 ether 00:0d:b9:3c:ae:25 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active and here are netstat output (no changes with previous): root@fbsd-router:~ # netstat -r4n Routing tables Internet: DestinationGatewayFlags Netif Expire 1.0.0.0/24 link#1 U re0 1.0.0.1link#1 UHS lo0 1.1.1.0/24 link#6 U bridge0 1.1.1.1link#6 UHS lo0 127.0.0.1 link#4 UH lo0 Because you didn't reach to reproduce with ix0 in place of wlan0, I've did some modification to my bridge setup: 1. In place of using re1+wlan0, I've put re1+re2 in the bridge0. And I've connected an host on re2: I didn't reach to reproduce the problem too, then I confirm we didn't have this bug with 2 Ethernet Interfaces. 2. In place of using PCI ath(4) (Atheros 9280), I've plugged an USB rum(4) (old Ralink) and configured it as wlan0 like was the ath0: the bridge0 was reverted to re1+wlan0. And I reach to reproduce the problem with a different wireless card: This thread seems correctly belong to the "wireless" mailing-list :-) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Installworld fails with TMPDIR pointing to NFS mounted directory
https://lists.freebsd.org/pipermail/freebsd-current/2010-September/019820.html Op 12 jan. 2016 20:39 schreef "Garrett Cooper" : > > On Jan 12, 2016, at 11:21, Tom Vijlbrief wrote: > > > Op di 12 jan. 2016 om 18:08 schreef NGie Cooper : > >> >> > On Jan 12, 2016, at 08:42, Tom Vijlbrief wrote: >> > >> > If have this issue with 11-CURRENT on my raspberry 1 and 2, but I do not >> > think it is raspberry related or even 11-CURRENT related. >> > >> > export TMPDIR=/media/usbdisk/tmp >> > >> > make installword MAKEOBJDIRPREFIX=/media/swan/obj >> >> Hi Tom, >> MAKEOBJDIRPREFIX should always be set via the environment, not >> the command line, e.g. >> >> export MAKEOBJDIRPREFIX=/media/swan/obj >> make installworld >> >> Cheers, >> -NGie > > > I think I actually did the export and not as I typed in my mail, > the export is in my shell history :-) > > I also added: > > rpc_lockd_enable="YES" > > to my /etc/rc.conf and rebooted (rpc.lockd is now running) as Bryan > suggested, but I don't think that it is needed if the only client accessing > the NFS tmp dir is the local client? > > [root@rpibsd /media/swan/src]# env | grep swan > TMPDIR=/media/swan/tmp > PWD=/media/swan/src > MAKEOBJDIRPREFIX=/media/swan/obj > > make installworld DESTDIR=/d/root11 > > Same result: > > ===> etc/sendmail (install) > cd /media/swan/src/etc/../share/man; make makedb > makewhatis /d/root11/usr/share/man > makewhatis /d/root11/usr/share/openssl/man > rm: /media/swan/tmp/install.sy3BjziY/locale/en_US.UTF-8: Directory not > empty > rm: /media/swan/tmp/install.sy3BjziY/locale: Directory not empty > rm: /media/swan/tmp/install.sy3BjziY: Directory not empty > *** Error code 1 > > Stop. > make[1]: stopped in /media/swan/src > *** Error code 1 > > Stop. > make: stopped in /media/swan/src > [root@rpibsd /media/swan/src]# > > > The NFS "directory not empty" issue has been a common annoyance for me for > several years. It's not just you... It deserves a bug though. > Thanks! > -NGie > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Installworld fails with TMPDIR pointing to NFS mounted directory
On 12 January 2016 at 19:42, Tom Vijlbrief wrote: > [..] > export TMPDIR=/media/swan/tmp > > The NFS server exports /media/swan which has a src/ obj/ and tmp/ > subdirectory. > src/ has the sources, obj/ is filled correctly by makeworld. > The tmp dir has the correct permissions. The installworld runs till the > end, except for the last cleanup action which fails: > > ===> etc/sendmail (install) > cd /media/swan/src/etc/../share/man; make makedb > makewhatis /d/root11/usr/share/man > makewhatis /d/root11/usr/share/openssl/man > rm: /media/swan/tmp/install.xrgbPMy8/locale/en_US.UTF-8: Directory not empty > rm: /media/swan/tmp/install.xrgbPMy8/locale: Directory not empty > rm: /media/swan/tmp/install.xrgbPMy8: Directory not empty > *** Error code 1 Search for NFS "sillyrename". -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: forwarding didn't work if wlan0 is member of a bridge
Ah, okay. Can you ping out the routed interface whilst this occurs? -a On 12 January 2016 at 12:48, Olivier Cochard-Labbé wrote: > On Tue, Jan 12, 2016 at 7:22 PM, Adrian Chadd > wrote: >> >> This is actually the intended behaviour, right? The routed interface >> is down, so the IP address on it and connected to it are unreachable. > > > Hi Adrian, > > the routed interface is a bridge interface, and this bridge interface had > only one of its 2 members interface down. > Then the routed interface is not down. > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: forwarding didn't work if wlan0 is member of a bridge
12.01.2016, 23:48, "Olivier Cochard-Labbé" : > On Tue, Jan 12, 2016 at 7:22 PM, Adrian Chadd > wrote: > >> This is actually the intended behaviour, right? The routed interface >> is down, so the IP address on it and connected to it are unreachable. > > Hi Adrian, > > the routed interface is a bridge interface, and this bridge interface had > only one of its 2 members interface down. > Then the routed interface is not down. Could you show 'netstat -rn' output when one of bridge members is down? Btw, I tried to reproduce it today (but, with ix0 instead of wlan0) and I wasn't able to trigger the problem. > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: forwarding didn't work if wlan0 is member of a bridge
On Tue, Jan 12, 2016 at 7:22 PM, Adrian Chadd wrote: > This is actually the intended behaviour, right? The routed interface > is down, so the IP address on it and connected to it are unreachable. > Hi Adrian, the routed interface is a bridge interface, and this bridge interface had only one of its 2 members interface down. Then the routed interface is not down. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Installworld fails with TMPDIR pointing to NFS mounted directory
> On Jan 12, 2016, at 11:21, Tom Vijlbrief wrote: > > > Op di 12 jan. 2016 om 18:08 schreef NGie Cooper : >> >> > On Jan 12, 2016, at 08:42, Tom Vijlbrief wrote: >> > >> > If have this issue with 11-CURRENT on my raspberry 1 and 2, but I do not >> > think it is raspberry related or even 11-CURRENT related. >> > >> > export TMPDIR=/media/usbdisk/tmp >> > >> > make installword MAKEOBJDIRPREFIX=/media/swan/obj >> >> Hi Tom, >> MAKEOBJDIRPREFIX should always be set via the environment, not the >> command line, e.g. >> >> export MAKEOBJDIRPREFIX=/media/swan/obj >> make installworld >> >> Cheers, >> -NGie > > I think I actually did the export and not as I typed in my mail, > the export is in my shell history :-) > > I also added: > > rpc_lockd_enable="YES" > > to my /etc/rc.conf and rebooted (rpc.lockd is now running) as Bryan > suggested, but I don't think that it is needed if the only client accessing > the NFS tmp dir is the local client? > > [root@rpibsd /media/swan/src]# env | grep swan > TMPDIR=/media/swan/tmp > PWD=/media/swan/src > MAKEOBJDIRPREFIX=/media/swan/obj > > make installworld DESTDIR=/d/root11 > > Same result: > > ===> etc/sendmail (install) > cd /media/swan/src/etc/../share/man; make makedb > makewhatis /d/root11/usr/share/man > makewhatis /d/root11/usr/share/openssl/man > rm: /media/swan/tmp/install.sy3BjziY/locale/en_US.UTF-8: Directory not empty > rm: /media/swan/tmp/install.sy3BjziY/locale: Directory not empty > rm: /media/swan/tmp/install.sy3BjziY: Directory not empty > *** Error code 1 > > Stop. > make[1]: stopped in /media/swan/src > *** Error code 1 > > Stop. > make: stopped in /media/swan/src > [root@rpibsd /media/swan/src]# The NFS "directory not empty" issue has been a common annoyance for me for several years. It's not just you... It deserves a bug though. Thanks! -NGie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Installworld fails with TMPDIR pointing to NFS mounted directory
Op di 12 jan. 2016 om 18:08 schreef NGie Cooper : > > > On Jan 12, 2016, at 08:42, Tom Vijlbrief wrote: > > > > If have this issue with 11-CURRENT on my raspberry 1 and 2, but I do not > > think it is raspberry related or even 11-CURRENT related. > > > > export TMPDIR=/media/usbdisk/tmp > > > > make installword MAKEOBJDIRPREFIX=/media/swan/obj > > Hi Tom, > MAKEOBJDIRPREFIX should always be set via the environment, not the > command line, e.g. > > export MAKEOBJDIRPREFIX=/media/swan/obj > make installworld > > Cheers, > -NGie I think I actually did the export and not as I typed in my mail, the export is in my shell history :-) I also added: rpc_lockd_enable="YES" to my /etc/rc.conf and rebooted (rpc.lockd is now running) as Bryan suggested, but I don't think that it is needed if the only client accessing the NFS tmp dir is the local client? [root@rpibsd /media/swan/src]# env | grep swan TMPDIR=/media/swan/tmp PWD=/media/swan/src MAKEOBJDIRPREFIX=/media/swan/obj make installworld DESTDIR=/d/root11 Same result: ===> etc/sendmail (install) cd /media/swan/src/etc/../share/man; make makedb makewhatis /d/root11/usr/share/man makewhatis /d/root11/usr/share/openssl/man rm: /media/swan/tmp/install.sy3BjziY/locale/en_US.UTF-8: Directory not empty rm: /media/swan/tmp/install.sy3BjziY/locale: Directory not empty rm: /media/swan/tmp/install.sy3BjziY: Directory not empty *** Error code 1 Stop. make[1]: stopped in /media/swan/src *** Error code 1 Stop. make: stopped in /media/swan/src [root@rpibsd /media/swan/src]# ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Whats the different between the two fingerprints?
On 2016-01-12 19:41, Allan Jude wrote: > On 2016-01-12 13:24, olli hauer wrote: >> Hi, >> >> whats the different between the two fingerprints ? >> >> 1) 23eb3a878c79d9c982ffe8e0041dfb5d7526d9bce868f60bcd51b00c86215d9f >> 2) 23EB3A878C79D9C982FFE8E0041DFB5D7526D9BCE868F60BCD51B00C86215D9F >> >> >> For human both are the same, but not if tested with >> (md5|sha1|sha256|sha512|rmd160) -c $string >> >> Unluckily some vendors providing fingerprints in uppercase (pointing e.g. to >> HP). >> The fix is really trivial to implement in src/sbin/md5/md5.c (low hanging >> fruit) >> >> If a dev with src commit has 5min, it would be nice if the one can look at >> PR 205598 >> > > there is a PR for this. It is being worked on. > Yes, I wrote the PR ;) Until now it was not taken and I would be very happy to see the fix in stable9/10 before 10.3 is released. -- olli ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Whats the different between the two fingerprints?
On 2016-01-12 13:24, olli hauer wrote: Hi, whats the different between the two fingerprints ? 1) 23eb3a878c79d9c982ffe8e0041dfb5d7526d9bce868f60bcd51b00c86215d9f 2) 23EB3A878C79D9C982FFE8E0041DFB5D7526D9BCE868F60BCD51B00C86215D9F For human both are the same, but not if tested with (md5|sha1|sha256|sha512|rmd160) -c $string Unluckily some vendors providing fingerprints in uppercase (pointing e.g. to HP). The fix is really trivial to implement in src/sbin/md5/md5.c (low hanging fruit) If a dev with src commit has 5min, it would be nice if the one can look at PR 205598 there is a PR for this. It is being worked on. -- Allan Jude ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Whats the different between the two fingerprints?
Hi, whats the different between the two fingerprints ? 1) 23eb3a878c79d9c982ffe8e0041dfb5d7526d9bce868f60bcd51b00c86215d9f 2) 23EB3A878C79D9C982FFE8E0041DFB5D7526D9BCE868F60BCD51B00C86215D9F For human both are the same, but not if tested with (md5|sha1|sha256|sha512|rmd160) -c $string Unluckily some vendors providing fingerprints in uppercase (pointing e.g. to HP). The fix is really trivial to implement in src/sbin/md5/md5.c (low hanging fruit) If a dev with src commit has 5min, it would be nice if the one can look at PR 205598 -- Thanks, olli ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: forwarding didn't work if wlan0 is member of a bridge
This is actually the intended behaviour, right? The routed interface is down, so the IP address on it and connected to it are unreachable. -a On 11 January 2016 at 14:52, Olivier Cochard-Labbé wrote: > After weeks of troubleshooting, at last I found how to reproduce this > problem ;-) > > Here is the setup: > > LAN0 <--> [(re0) fbsd router (bridge0 addm re1 addm wlan0)] <--> Wireless > LAN > > If interface re1 (bridge0 member with wlan0) is in "active" status > (=ethernet cable plugged to something): I don't have any problem, all is > working great for my wireless clients connected to wlan0: They can ping > devices in LAN0. > But once I've unplug the ethernet cable connected to re1 (bridge member > with wlan0) and re1 state switch to "no carrier", Wireless LAN clients are > not able to reach LAN0. > > Here is my rc.conf with simple subnetting for Adrian ;-) > > wlans_ath0="wlan0" > ifconfig_wlan0="hostap channel 6" > create_args_wlan0="wlanmode hostap" > cloned_interfaces="bridge0" > ifconfig_re0="inet 1.0.0.1/24" > ifconfig_re1="up" > ifconfig_bridge0="inet 1.1.1.1/24 addm re1 addm wlan0 up" > gateway_enable="YES" > > And an example with re1 in "no carrier" status: > > root@fbsd-router:~ # ifconfig bridge0 > bridge0: flags=8843 metric 0 mtu > 1500 > ether 02:6b:c0:de:b8:00 > inet 1.1.1.1 netmask 0xff00 broadcast 1.1.1.255 > nd6 options=9 > groups: bridge > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: wlan0 flags=143 > ifmaxaddr 0 port 5 priority 128 path cost 3 > member: re1 flags=143 > ifmaxaddr 0 port 2 priority 128 path cost 55 > > > root@fbsd-router:~ # ifconfig re1 > re1: flags=8943 metric 0 > mtu 1500 > > options=82099 > ether 00:0d:b9:3c:ae:25 > nd6 options=29 > media: Ethernet autoselect (none) > status: no carrier > > => from a wireless LAN client (1.1.1.2) I'm trying to ping a host on LAN0 > (1.0.0.2): > > root@fbsd-router:~ # tcpdump -pni re0 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes > 23:38:04.466866 ARP, Request who-has 1.0.0.2 tell 1.0.0.1, length 28 > 23:38:04.467052 ARP, Reply 1.0.0.2 is-at 00:08:a2:09:c4:a2, length 46 > 23:38:04.467090 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 1, > length 64 > 23:38:04.467226 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 1, length > 64 > 23:38:04.467300 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length > 36 > 23:38:05.483053 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 2, > length 64 > 23:38:05.483259 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 2, length > 64 > 23:38:05.483318 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length > 36 > 23:38:06.387304 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 3, > length 64 > 23:38:06.387466 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 3, length > 64 > 23:38:06.387514 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length > 36 > ^C > 11 packets captured > 11 packets received by filter > 0 packets dropped by kernel > root@fbsd-router:~ # arp -na > ? (1.1.1.1) at 02:6b:c0:de:b8:00 on bridge0 permanent [bridge] > ? (1.1.1.2) at fc:64:ba:97:c0:ff on bridge0 expires in 1168 seconds [bridge] > ? (1.0.0.1) at 00:0d:b9:3c:ae:24 on re0 permanent [ethernet] > > => The FreeBSD router answers "unreacheable" to the host: My wireless LAN > client never get the ICMP reply. > > => Now I plug eth1 to a dummy machine (just for changing its status): > > root@fbsd-router:~ # ifconfig re1 > re1: flags=8943 metric 0 > mtu 1500 > > options=82099 > ether 00:0d:b9:3c:ae:25 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > > => and I restart the same ping from the wireless LAN client: > > root@fbsd-router:~ # tcpdump -pni re0 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes > 23:44:08.597429 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 1, > length 64 > 23:44:08.597660 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 74, seq 1, length > 64 > 23:44:09.604447 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 2, > length 64 > 23:44:09.604683 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 74, seq 2, length > 64 > 23:44:10.609711 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 3, > length 64 > 23:44:10.609874 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 74, seq 3, length > 64 > > => It's works :-) > > How the status of a member of the bridge can impact the routing behavior of > other interfaces ? > How to fix this problem ? > > Thanks > ___ > freebsd-current@freebsd.org mailing list > https://l
Re: forwarding didn't work if wlan0 is member of a bridge
On Mon, 11 Jan 2016 23:52:47 +0100 Olivier Cochard-Labbé wrote: > > After weeks of troubleshooting, at last I found how to reproduce this > problem ;-) > > Here is the setup: > > LAN0 <--> [(re0) fbsd router (bridge0 addm re1 addm wlan0)] <--> Wireless > LAN > > If interface re1 (bridge0 member with wlan0) is in "active" status > (=ethernet cable plugged to something): I don't have any problem, all is > working great for my wireless clients connected to wlan0: They can ping > devices in LAN0. > But once I've unplug the ethernet cable connected to re1 (bridge member > with wlan0) and re1 state switch to "no carrier", Wireless LAN clients are > not able to reach LAN0. > > Here is my rc.conf with simple subnetting for Adrian ;-) > > wlans_ath0="wlan0" > ifconfig_wlan0="hostap channel 6" > create_args_wlan0="wlanmode hostap" > cloned_interfaces="bridge0" > ifconfig_re0="inet 1.0.0.1/24" > ifconfig_re1="up" > ifconfig_bridge0="inet 1.1.1.1/24 addm re1 addm wlan0 up" > gateway_enable="YES" > > And an example with re1 in "no carrier" status: > > root@fbsd-router:~ # ifconfig bridge0 > bridge0: flags=8843 metric 0 mtu > 1500 > ether 02:6b:c0:de:b8:00 > inet 1.1.1.1 netmask 0xff00 broadcast 1.1.1.255 > nd6 options=9 > groups: bridge > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: wlan0 flags=143 > ifmaxaddr 0 port 5 priority 128 path cost 3 > member: re1 flags=143 > ifmaxaddr 0 port 2 priority 128 path cost 55 > > > root@fbsd-router:~ # ifconfig re1 > re1: flags=8943 metric 0 > mtu 1500 > > options=82099 > ether 00:0d:b9:3c:ae:25 > nd6 options=29 > media: Ethernet autoselect (none) > status: no carrier > > => from a wireless LAN client (1.1.1.2) I'm trying to ping a host on LAN0 > (1.0.0.2): > > root@fbsd-router:~ # tcpdump -pni re0 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes > 23:38:04.466866 ARP, Request who-has 1.0.0.2 tell 1.0.0.1, length 28 > 23:38:04.467052 ARP, Reply 1.0.0.2 is-at 00:08:a2:09:c4:a2, length 46 > 23:38:04.467090 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 1, > length 64 > 23:38:04.467226 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 1, length > 64 > 23:38:04.467300 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length > 36 > 23:38:05.483053 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 2, > length 64 > 23:38:05.483259 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 2, length > 64 > 23:38:05.483318 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length > 36 > 23:38:06.387304 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 3, > length 64 > 23:38:06.387466 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 3, length > 64 > 23:38:06.387514 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length > 36 > ^C > 11 packets captured > 11 packets received by filter > 0 packets dropped by kernel > root@fbsd-router:~ # arp -na > ? (1.1.1.1) at 02:6b:c0:de:b8:00 on bridge0 permanent [bridge] > ? (1.1.1.2) at fc:64:ba:97:c0:ff on bridge0 expires in 1168 seconds [bridge] > ? (1.0.0.1) at 00:0d:b9:3c:ae:24 on re0 permanent [ethernet] > > => The FreeBSD router answers "unreacheable" to the host: My wireless LAN > client never get the ICMP reply. > > => Now I plug eth1 to a dummy machine (just for changing its status): > > root@fbsd-router:~ # ifconfig re1 > re1: flags=8943 metric 0 > mtu 1500 > > options=82099 > ether 00:0d:b9:3c:ae:25 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > > => and I restart the same ping from the wireless LAN client: > > root@fbsd-router:~ # tcpdump -pni re0 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes > 23:44:08.597429 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 1, > length 64 > 23:44:08.597660 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 74, seq 1, length > 64 > 23:44:09.604447 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 2, > length 64 > 23:44:09.604683 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 74, seq 2, length > 64 > 23:44:10.609711 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 3, > length 64 > 23:44:10.609874 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 74, seq 3, length > 64 > > => It's works :-) > > How the status of a member of the bridge can impact the routing behavior of > other interfaces ? > How to fix this problem ? > > Thanks > ___ > freebsd-wirel...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@
Re: Installworld fails with TMPDIR pointing to NFS mounted directory
> On Jan 12, 2016, at 08:42, Tom Vijlbrief wrote: > > If have this issue with 11-CURRENT on my raspberry 1 and 2, but I do not > think it is raspberry related or even 11-CURRENT related. > > export TMPDIR=/media/usbdisk/tmp > > make installword MAKEOBJDIRPREFIX=/media/swan/obj Hi Tom, MAKEOBJDIRPREFIX should always be set via the environment, not the command line, e.g. export MAKEOBJDIRPREFIX=/media/swan/obj make installworld Cheers, -NGie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Installworld fails with TMPDIR pointing to NFS mounted directory
On 1/12/16 8:42 AM, Tom Vijlbrief wrote: > If have this issue with 11-CURRENT on my raspberry 1 and 2, but I do not > think it is raspberry related or even 11-CURRENT related. > > export TMPDIR=/media/usbdisk/tmp > > make installword MAKEOBJDIRPREFIX=/media/swan/obj > > Works as expected but fails cleaning up when TMPDIR points to an NFS > mounted directory: > > export TMPDIR=/media/swan/tmp > > The NFS server exports /media/swan which has a src/ obj/ and tmp/ > subdirectory. > src/ has the sources, obj/ is filled correctly by makeworld. > The tmp dir has the correct permissions. The installworld runs till the > end, except for the last cleanup action which fails: > > ===> etc/sendmail (install) > cd /media/swan/src/etc/../share/man; make makedb > makewhatis /d/root11/usr/share/man > makewhatis /d/root11/usr/share/openssl/man > rm: /media/swan/tmp/install.xrgbPMy8/locale/en_US.UTF-8: Directory not empty > rm: /media/swan/tmp/install.xrgbPMy8/locale: Directory not empty > rm: /media/swan/tmp/install.xrgbPMy8: Directory not empty > *** Error code 1 Well, it's not really a build or installworld problem. Are you running the proper NFS daemons for lock/rpc? > > Stop. > make[1]: stopped in /media/swan/src > *** Error code 1 > > Stop. > make: stopped in /media/swan/src > > On some runs just a single error message that complains about: > /media/swan/tmp/install.xyz > not being empty, but an "ls" shows no files and an "rmdir /media/swan/tmp/ > install.xyz" succeeds! > In the example above "/media/swan/tmp/install.xrgbPMy8/locale/en_US.UTF-8" > IS empty! > > It is as if a removed file remains visible for the client for a while. > > The NFS server is running Ubuntu 15.10, NFSv3 is used, no other clients > access the NFS tmp directory, > no error messages on the client or server dmesg. > > /etc/exports on the server: > > /export/all/bsd > 192.168.0.0/24(rw,no_root_squash,nohide,insecure,no_subtree_check,async) > > The systems have completed many build/install world/kernel cycles using > this NFS mount and are rock solid. > > Any hints would be appreciated. > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Regards, Bryan Drewery ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Need help with New Build -- Skylake
On 12/24/15, Konstantin Belousov wrote: > On Thu, Dec 24, 2015 at 08:29:20AM -0700, Ian Lepore wrote: >> We had exactly this symptom -- long delay with spincursor before >> loading the kernel -- on arm systems when we first enabled forth in >> loader. The problem turned out to be the fact that loader was running >> with instruction and data caches disabled, and it took about 90-100 >> seconds to parse the 547 lines of text (almost all useless) in >> /boot/defaults/loader.conf. We stripped that file down to the dozen or >> so lines that actually needed to be there and booting became much >> faster. Eventually we got the caches enabled in the prior-stage >> bootloader and it became really fast. > > It is highly unlikely that caches are the source of the slowness. On > x86, we rely on the firmware (BIOS or EFI) to properly configure both > DRAM controllers and caches. More, Intel considers the corresponding > controllers configuration recipes as highly secret and, even for BIOS > vendors, Intel provides the binary blob of code which does the config > magic, instead of the documentation. > > That said, loader runs in the unpaged protected mode but reflects BIOS > calls into the real mode. Quite possible, either the real mode is > slow on SkyLakes, or even more possible, the switch between real and > protected mode is slow, or the protected mode without paging enabled is > slow. Or might be the PCH lacks the ISA timer. Seem like the issue is affects the legacy boot mode, in UEFI mode the system boots blazingly fast. When I have more time, I try to figure out what's the problem behind this issue. > > A developer needs the real machine to diagnose the cause. > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Installworld fails with TMPDIR pointing to NFS mounted directory
If have this issue with 11-CURRENT on my raspberry 1 and 2, but I do not think it is raspberry related or even 11-CURRENT related. export TMPDIR=/media/usbdisk/tmp make installword MAKEOBJDIRPREFIX=/media/swan/obj Works as expected but fails cleaning up when TMPDIR points to an NFS mounted directory: export TMPDIR=/media/swan/tmp The NFS server exports /media/swan which has a src/ obj/ and tmp/ subdirectory. src/ has the sources, obj/ is filled correctly by makeworld. The tmp dir has the correct permissions. The installworld runs till the end, except for the last cleanup action which fails: ===> etc/sendmail (install) cd /media/swan/src/etc/../share/man; make makedb makewhatis /d/root11/usr/share/man makewhatis /d/root11/usr/share/openssl/man rm: /media/swan/tmp/install.xrgbPMy8/locale/en_US.UTF-8: Directory not empty rm: /media/swan/tmp/install.xrgbPMy8/locale: Directory not empty rm: /media/swan/tmp/install.xrgbPMy8: Directory not empty *** Error code 1 Stop. make[1]: stopped in /media/swan/src *** Error code 1 Stop. make: stopped in /media/swan/src On some runs just a single error message that complains about: /media/swan/tmp/install.xyz not being empty, but an "ls" shows no files and an "rmdir /media/swan/tmp/ install.xyz" succeeds! In the example above "/media/swan/tmp/install.xrgbPMy8/locale/en_US.UTF-8" IS empty! It is as if a removed file remains visible for the client for a while. The NFS server is running Ubuntu 15.10, NFSv3 is used, no other clients access the NFS tmp directory, no error messages on the client or server dmesg. /etc/exports on the server: /export/all/bsd 192.168.0.0/24(rw,no_root_squash,nohide,insecure,no_subtree_check,async) The systems have completed many build/install world/kernel cycles using this NFS mount and are rock solid. Any hints would be appreciated. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Xen/dom0/FreeBSD + NAS4Free WebGUI.
El 29/12/15 a les 7.27, Daisuke Aoyama ha escrit: > Hello, > > -- > From: "Roger Pau Monne" > Sent: Monday, December 28, 2015 10:20 PM > To: "Daisuke Aoyama" ; > Cc: > Subject: Re: Xen/dom0/FreeBSD + NAS4Free WebGUI. > >> Hello, >> >> El 26/12/15 a les 15.26, Daisuke Aoyama ha escrit: >>> Hi all, >>> >>> I'm creating NAS4Free dom0 edition. >>> This is simple wrapper of Xen/dom0/FreeBSD. >>> >>> You can upgrade by same way of NAS4Free. >>> You can manage HDD, ZFS, iSCSI target, NFS share by same way of >>> NAS4Free. >>> You can manage DomU(VM) via WebGUI. >>> >>> Japanese blog: >>> http://shell.peach.ne.jp/aoyama/archives/3149 >>> http://shell.peach.ne.jp/aoyama/archives/3135 >>> >>> NAS4Free dom0 topic in English: >>> http://forums.nas4free.org/viewtopic.php?f=17&t=10028 >>> >>> Latest download: >>> http://www.peach.ne.jp/archives/nas4free/test/2244-dom0/ >>> >>> How to install: >>> 1.Download LiveCD iso image. >>> 2.Burn to CD/DVD-RW blank disc. >>> 3.Boot from it. >>> (if your server don't have an optical drive, please use an external USB >>> optical drive) >>> 4.Install to USB Flash drive (2GB or more) from menu #9. >>> 5.Reboot the server after ejecting CD/DVD media. >>> >>> How to upgrade: >>> 1.Navigate to System|Firmware in global menu from web browser. >>> 2.Click "Enable Firmware Update". >>> 3.Select NAS4Free-dom0-embedded-*.img.xz. (don't decompress the image) >>> 4.Click "Upgrade Firmware". > > I forget to write. You should backup the config from > System|Backup/Restore before upgrading. > >>> >>> Note: >>> At least you need a bridge interface before using. >>> Please create it from Network|Interface Management|Bridge. >>> You can change boot parameters from System|Advanced|loader.conf. >>> If you are interested in the xl.cfg, it is created in >>> /usr/local/etc/xen/vm-.cfg. >> >> Thanks for doing this, I just gave it a try and it worked out of the >> box, I was able to create and launch a Windows VM in less than 2min, >> quite impressive :). > > Thank you for trying. > >> >>> Known issues: >>> uuid generation of ports/sysutils/xen-tools is broken. You cannot >>> control by UUID. >>> (quick hack patch is attached this mail) >> >> I've given a look at the patch, but I have to admit I know very little >> about UUID, yet it seems like you should not poke directly at the >> internal uuid_t fields. I've created another patch which I *think* >> should solve the UUID issues, could you test it please? It should apply >> cleanly against Xen 4.5. >> >> https://people.freebsd.org/~royger/uuid.patch > > Your patch does not work as expected. > You can test it under normal FreeBSD. First create UUID by uuidgen(1): > > # uuidgen > 4c90eb5a-adee-11e5-a747-001b2157b424 > > Insert the UUID to your VM config (see also > /usr/local/etc/xen/vm-.cfg): > uuid = "4c90eb5a-adee-11e5-a747-001b2157b424" > > Run the VM: > # xl create name.cfg > > Check by xl list: > # xl list -v > # xl list -l > > Your patched result is here: > [root@nas4free-xen ~]# xl list -v > NameID Mem VCPUs State > Time(s) UUID Reason-Code Security Label > Domain-0 0 4096 4 > r- 202.8 ---- > -- > nas4free 4 2048 2 > -b 51.1 ---- > -- > >>> xnb device performance is terrible. >>> (it eats 100% CPU on intr while transferring via bridged 10GbE) >> >> I haven't seen this, but I'm not surprised (I also don't have a 10GbE >> card at hand right now). There's a lot of fine tuning and bug fixing to >> do regarding the backends. I plan to get with this once the PVH >> implementation is stable. > > I feel UUID is very small thing than performance 70% drop down via xnb. Hello, Could you please test the following patch, it should fix UUID: https://people.freebsd.org/~royger/0001-libxl-fix-UUID-usage-on-FreeBSD.patch I understand that the netback performance issue is a big handicap, I will try to find some time to look into it, but I have to admit my plate is quite full at the moment and it doesn't look like a trivial issue (like the UUID one). I'm adding Wei to the Cc, he has been working on netfront improvements, so maybe he also wants to take a stab at netback ;). Roger. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
