fib 1 DHCP and RA default route
I'm setting up a new router that has both an ADSL/PPPoE and a cable modem upstream. I've configured mpd5 for the PPPoE connection, and I'd like to have the cable modem provide a second, independent connection through FIB 1 over igb2. rc.conf (partially): ifconfig_igb2_descr="Cable Modem" ifconfig_igb2="DHCP fib 1" ifconfig_igb2_ipv6="inet6 accept_rtadv defaultif" gateway_enable="YES" ipv6_gateway_enable="YES" pf_enable="YES" dhclient_flags="-b" dhcp6c_enable="YES" dhcp6c_interfaces="igb2" dhcp6c_fib=1 I think this should be sufficient to receive both an IPv4 and IPv6 address and a default route, however, neither one is added. When I manually add them, they are removed after a while. $ ifconfig igb2 igb2: flags=8863 metric 0 mtu 1500 description: Cable Modem options=4e527bb ether 00:0d:b9:xx:xx:62 inet6 fe80::20d:b9ff:fe58:5262%igb2 prefixlen 64 scopeid 0x3 inet6 2a02:8108:0:90::8eb4:28c2:6315 prefixlen 128 inet 31.16.xxx.4 netmask 0xff00 broadcast 31.16.xxx.255 fib: 1 media: Ethernet autoselect (1000baseT ) status: active nd6 options=8023 $ setfib 1 netstat -rnfinet Routing tables (fib: 1) Internet: DestinationGatewayFlags Netif Expire 31.16.xxx.0/24 link#3 U igb2 31.16.xxx.4link#3 UHS lo0 127.0.0.1 link#4 UHS lo0 $ setfib 1 netstat -rnfinet6 Routing tables (fib: 1) Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRSlo0 ::1 link#4UHS lo0 :::0.0.0.0/96 ::1 UGRSlo0 2a02:8108:0:90::8eb4:28c2:6315 link#3 UHS lo0 2a02:8108::9d00::/64 link#17 U br103 2a02:8108::9d00:0:ff:fe00:367 link#17 UHS lo0 fe80::/10 ::1 UGRSlo0 fe80::%igb2/64link#3U igb2 fe80::20d:b9ff:fe58:5262%igb2 link#3UHS lo0 ff02::/16 ::1 UGRSlo0 For IPv6, I thought that setting defaultif would make the kernel add the default route when an appropriate RA is received, and on my old router, that was working; I can't seem to see what difference I have in the config, apart from using FIB 1 instead of the default. And for IPv4, I see that I get the default router through DHCP, but somehow /sbin/dhclient-script is not adding a default route. If I add it manually, it will be removed eventually. Any suggestions? Stefan -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP
Re: Bridge interface on VLAN not working
Am 04.07.2020 um 20:59 schrieb Ask Bjørn Hansen : > > Hi everyone, > > I had this working for months until a reboot either got things started up in > a different order or cleared what I setup by hand (it’s a snowflake > test/development system at home) and did whatever I’d actually configured. > > I have a single trunk’ed (em) interface to the switch. The main network is > untagged, and I have various tagged networks as well. I was using the tagged > networks in bhyve virtual machines. > > (Some?) traffic doesn’t pass from the bridged tap interfaces (or from the > bridge itself) to the vlan interface (em0.8 for example). tcpdump shows lots > of packets coming from the “outside” and in, but for example if I do a ping > from one of the tap interfaces then nothing shows up on the bridge interface > (looking with tcpdump). > > Another symptom is that if I move the “host IP” from the em0.8 interface to > the bridge interface that’s including em0.8 then I can no longer communicate > with that IP from the rest of the network. > > In the output below I can ping 192.168.53.42 from another system on VLAN 53 > (outside this box) and I can ping 192.168.53.42 from another system on the > bridge, but I can’t ping between the system outside this box and the VM on > the bridge. > > I’ve disabled pf everywhere. > > As I mentioned, some traffic crosses but it seems like arp requests gets > blocked somewhere? > > I don’t think it’s the switch, because as long as I don’t use the bridge > everything works fine. :-/ > > Any suggestions? (or other debug output that’d be useful). Which kernel version are you running? I have a similar setup, but all my VLANs are tagged. I have an OpenVPN connection with a bridge, and originally was bridging the untagged interface over that. Since the untagged interface includes all the .1q frames as well, and I didn't want that traffic on the VPN connection, I changed my config to tagged only, and moved to bridging only the VLAN interfaces, but not the physical one. I've followed the advice in the man page and have configured IPv4 and IPv6 only on the bridge interface, not the member interfaces. I have two more systems that also use a VLAN/bridge setup. I'm using PF, but I have restricted it (from the defaults) to only work on the IP layer and on the configured interface, not the bridge members and not on bridged packets. In my setup, the bridge conceptually should behave like an external switch. I'm running 12.1-STABLE amd64 GENERIC 1201518, and I have these interfaces (one example VLAN, I have 4 in total): ix0: flags=8943 metric 0 mtu 1500 options=e53fbb ether d0:50:99:d8:da:83 media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 vlan100: flags=8943 metric 0 mtu 1500 options=200401 ether d0:50:99:d8:da:83 groups: vlan vlan: 100 vlanpcp: 0 parent interface: ix0 media: Ethernet autoselect (1000baseT ) status: active nd6 options=49 br100: flags=8843 metric 0 mtu 1500 description: vm-br100 ether 02:00:00:00:00:64 inet 44.128. netmask 0xff00 broadcast 44.128. inet 44.128. netmask 0x broadcast 44.128. inet 44.128. netmask 0x broadcast 44.128. inet6 fe80::ff:fe00:64%br100 prefixlen 64 scopeid 0x10 inet6 2a02:8108::0:ff:fe00:64 prefixlen 64 inet6 2a02:8108:::2 prefixlen 128 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: jous flags=143 ifmaxaddr 0 port 30 priority 128 path cost 2000 member: jouk flags=143 ifmaxaddr 0 port 29 priority 128 path cost 2000 member: tap2 flags=143 ifmaxaddr 0 port 9 priority 128 path cost 200 member: vlan100 flags=143 ifmaxaddr 0 port 12 priority 128 path cost 2000 groups: bridge vm-switch viid-b8446@ nd6 options=61 -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP
SR_IOV with ixgbe not working?
I just started using an ASRock Rack X470D4U2-2T:
https://www.asrockrack.com/general/productdetail.asp?Model=X470D4U2-2T#Specifications
<https://www.asrockrack.com/general/productdetail.asp?Model=X470D4U2-2T#Specifications>
It sports an X550 dual 10G ethernet controller:
# pciconf -lv
ix0@pci0:1:0:0: class=0x02 card=0x15631849 chip=0x15638086 rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Controller 10G X550T'
class = network
subclass = ethernet
ix1@pci0:1:0:1: class=0x02 card=0x15631849 chip=0x15638086 rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Controller 10G X550T'
class = network
subclass = ethernet
It should support SR-IOV:
# ls -l /dev/iov
total 0
crw--- 1 root wheel 0x32 Jun 20 23:04 ix0
crw--- 1 root wheel 0x33 Jun 20 23:04 ix1
# iovctl -S -d ix1
The following configuration parameters may be configured on the PF:
num_vfs : uint16_t (required)
device : string (required)
The following configuration parameters may be configured on a VF:
passthrough : bool (default = false)
mac-addr : unicast-mac (optional)
mac-anti-spoof : bool (default = true)
allow-set-mac : bool (default = false)
allow-promisc : bool (default = false)
If I try to create a number of virtual devices, things don't seem to work out:
# cat /etc/iovctl-ix1.conf
PF {
device: "ix1";
num_vfs: 8;
}
DEFAULT {
passthrough: true;
}
VF-0 {
passthrough: false;
}
# iovctl -C -f /etc/iovctl-ix1.conf
# dmesg
...
ixv0: at device 0.129 on
pci1
ixv0: ...reset_hw() failure: Reset Failed!
ixv0: IFDI_ATTACH_PRE failed 5
device_attach: ixv0 attach returned 5
pci1: at device 0.131 (no driver attached)
pci1: at device 0.133 (no driver attached)
pci1: at device 0.135 (no driver attached)
pci1: at device 0.137 (no driver attached)
pci1: at device 0.139 (no driver attached)
pci1: at device 0.141 (no driver attached)
pci1: at device 0.143 (no driver attached)
I haven't tried the passthrough devices yet, but I am interested in having at
least one virtual device available in the host for use with a VIMAGE jail.
# uname -a
FreeBSD diesel.lassitu.de <http://diesel.lassitu.de/> 12.1-STABLE FreeBSD
12.1-STABLE r362450 GENERIC amd64
Should this be working? It seems some months ago it was necessary to compile
the Intel driver instead of the in-tree one. I would have assumed that it would
have been integrated by now.
Stefan
--
Stefan Bethke mailto:s...@lassitu.de>> Fon +49 151 14070811
signature.asc
Description: Message signed with OpenPGP
SR_IOV with ixgbe not working?
I just started using an ASRock Rack X470D4U2-2T:
https://www.asrockrack.com/general/productdetail.asp?Model=X470D4U2-2T#Specifications
<https://www.asrockrack.com/general/productdetail.asp?Model=X470D4U2-2T#Specifications>
It sports an X550 dual 10G ethernet controller:
# pciconf -lv
ix0@pci0:1:0:0: class=0x02 card=0x15631849 chip=0x15638086 rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Controller 10G X550T'
class = network
subclass = ethernet
ix1@pci0:1:0:1: class=0x02 card=0x15631849 chip=0x15638086 rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Controller 10G X550T'
class = network
subclass = ethernet
It should support SR-IOV:
# ls -l /dev/iov
total 0
crw--- 1 root wheel 0x32 Jun 20 23:04 ix0
crw--- 1 root wheel 0x33 Jun 20 23:04 ix1
# iovctl -S -d ix1
The following configuration parameters may be configured on the PF:
num_vfs : uint16_t (required)
device : string (required)
The following configuration parameters may be configured on a VF:
passthrough : bool (default = false)
mac-addr : unicast-mac (optional)
mac-anti-spoof : bool (default = true)
allow-set-mac : bool (default = false)
allow-promisc : bool (default = false)
If I try to create a number of virtual devices, things don't seem to work out:
# cat /etc/iovctl-ix1.conf
PF {
device: "ix1";
num_vfs: 8;
}
DEFAULT {
passthrough: true;
}
VF-0 {
passthrough: false;
}
# iovctl -C -f /etc/iovctl-ix1.conf
# dmesg
...
ixv0: at device 0.129 on
pci1
ixv0: ...reset_hw() failure: Reset Failed!
ixv0: IFDI_ATTACH_PRE failed 5
device_attach: ixv0 attach returned 5
pci1: at device 0.131 (no driver attached)
pci1: at device 0.133 (no driver attached)
pci1: at device 0.135 (no driver attached)
pci1: at device 0.137 (no driver attached)
pci1: at device 0.139 (no driver attached)
pci1: at device 0.141 (no driver attached)
pci1: at device 0.143 (no driver attached)
I haven't tried the passthrough devices yet, but I am interested in having at
least one virtual device available in the host for use with a VIMAGE jail.
# uname -a
FreeBSD diesel.lassitu.de 12.1-STABLE FreeBSD 12.1-STABLE r362450 GENERIC amd64
Should this be working? It seems some months ago it was necessary to compile
the Intel driver instead of the in-tree one. I would have assumed that it would
have been integrated by now.
Stefan
--
Stefan BethkeFon +49 151 14070811
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 NDP triggering QuaggaLinux problem?
Am 13.01.2018 um 23:06 schrieb Stefan Bethke : > > Hey guys, > > I’m a bit stumped and are hoping for some helpful pointers. > > I have two machines both running a recent 11-stable (SuperMicro X11SSH-F with > a E3-1240v6); each one is connected to one Ethernet switch through igb0, and > back-to-back connected to the other box through igb1. igb1 only has IPv4 RFC > 1918 addresses configured. > > To make it easier to give bhyve VMs a public IP, igb0 is added as a member to > brigde0, and all addresses are configured on bridge0. The hosts run a small > number of jails with addresses on bridge0 as well. > > Whenever IPv6 is active on bridge0, my ISPs router (which is some version of > Quagga running on Linux) keeps filling up it’s routing table within minutes; > then traffic stops, the routing table is cleared and the normal set of > entries is installed, and traffic resumes. This pattern then repeats. The > router apparent has has full table with ~46000 routes normally, but within > minutes, the Linux kernel routing table gets filled up with multiple copies > of that. I believe that is is likely a problem with Quagga on Linux, and > ultimately has to be resolved there, but the question lingers what my two > systems could be sending that could trigger this. > > The ISP and I have looked at NDP config, tcpdumps of NDP, and general IPv6 > config, but we cannot identify why Quagga or the Linux kernel would behave > that way. Other FreeBSD boxes connected to the same router (but different > IPv6 /64s) do not trigger this behaviour. > > My systems are not really loaded, and traffic is light. One box gets about 50 > packet/s, the other about 400 (this one is in the NTP pool, and running a DNS > server). > > I’ve tried switching off NUD, but that doesn’t change the behaviour of the > Quagga system. > > Here’s some output of the current configuration: > # ifconfig igb0; ifconfig bridge0 > igb0: flags=8943 metric 0 mtu > 1500 > > options=6403bb > ether ac:1f:6b:18:xx:6e > hwaddr ac:1f:6b:18:xx:6e > inet6 fe80::ae1f:6bff:fexx:66e%igb0 prefixlen 64 tentative scopeid 0x1 > nd6 options=8 > media: Ethernet autoselect (1000baseT ) > status: active > bridge0: flags=8843 metric 0 mtu 1500 > description: vm-bridge0 > ether 02:3c:9f:37:xx:00 > inet 212.12.xx.225 netmask 0xffe0 broadcast 212.12.xx.255 > inet 212.12.xx.226 netmask 0x broadcast 212.12.xx.226 > inet 212.12.xx.253 netmask 0x broadcast 212.12.xx.253 > inet 212.12.xx.229 netmask 0x broadcast 212.12.xx.229 > inet6 fe80::3c:9fff:fe37:xx00%bridge0 prefixlen 64 scopeid 0x7 > inet6 2a00:14b0:4200:32xx::1e1 prefixlen 64 > inet6 2a00:14b0:4200:32xx::1e2 prefixlen 128 > inet6 2a00:14b0:4200:32xx::1fd prefixlen 128 > inet6 2a00:14b0:4200:32xx::1e5 prefixlen 128 > nd6 options=8020 > 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: igb0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 200 > # ndp -an > Neighbor Linklayer Address Netif ExpireS > Flags > 2a00:14b0:4200:32xx::1e1 02:3c:9f:37:xx:00 bridge0 permanent R > 2a00:14b0:4200:32xx::1 00:50:56:a1:xx:b5 bridge0 23h59m58s S R > 2a00:14b0:4200:32xx::1e2 02:3c:9f:37:xx:00 bridge0 permanent R > 2a00:14b0:4200:32xx::1e5 02:3c:9f:37:xx:00 bridge0 permanent R > 2a00:14b0:4200:32xx::1e7 02:5a:1d:92:xx:00 bridge0 23h59m16s S > 2a00:14b0:4200:32xx::1e8 02:5a:1d:92:xx:00 bridge0 23h59m2s S > 2a00:14b0:4200:32xx::1eb 02:5a:1d:92:xx:00 bridge0 23h55m7s S > 2a00:14b0:4200:32xx::1ea 02:5a:1d:92:xx:00 bridge0 23h2m24s S > fe80::3c:9fff:fe37:2500%bridge0 02:3c:9f:37:xx:00 bridge0 permanent R > fe80::250:56ff:fea1:dfb5%bridge0 00:50:56:a1:xx:b5 bridge0 23h59m57s S R > 2a00:14b0:4200:32e0::1fd 02:3c:9f:37:xx:00 bridge0 permanent R > fe80::ae1f:6bff:fe18:xx6f%igb1ac:1f:6b:18:xx:6f igb1 permanent R > fe80::ae1f:6bff:fe18:xx6e%igb0ac:1f:6b:18:xx:6e igb0 permanent R > # ndp -i bridge0 > linkmtu=0, maxmtu=0, curhlim=64, basereachable=30s0ms, reachable=32s, > retrans=1s0ms > Flags: auto_linklocal One more data point: on the Quagga machine, my ISP is seeing this: # ip -6 route show | grep 2a00:14b0:4200:32xx 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:
IPv6 NDP triggering QuaggaLinux problem?
Hey guys, I’m a bit stumped and are hoping for some helpful pointers. I have two machines both running a recent 11-stable (SuperMicro X11SSH-F with a E3-1240v6); each one is connected to one Ethernet switch through igb0, and back-to-back connected to the other box through igb1. igb1 only has IPv4 RFC 1918 addresses configured. To make it easier to give bhyve VMs a public IP, igb0 is added as a member to brigde0, and all addresses are configured on bridge0. The hosts run a small number of jails with addresses on bridge0 as well. Whenever IPv6 is active on bridge0, my ISPs router (which is some version of Quagga running on Linux) keeps filling up it’s routing table within minutes; then traffic stops, the routing table is cleared and the normal set of entries is installed, and traffic resumes. This pattern then repeats. The router apparent has has full table with ~46000 routes normally, but within minutes, the Linux kernel routing table gets filled up with multiple copies of that. I believe that is is likely a problem with Quagga on Linux, and ultimately has to be resolved there, but the question lingers what my two systems could be sending that could trigger this. The ISP and I have looked at NDP config, tcpdumps of NDP, and general IPv6 config, but we cannot identify why Quagga or the Linux kernel would behave that way. Other FreeBSD boxes connected to the same router (but different IPv6 /64s) do not trigger this behaviour. My systems are not really loaded, and traffic is light. One box gets about 50 packet/s, the other about 400 (this one is in the NTP pool, and running a DNS server). I’ve tried switching off NUD, but that doesn’t change the behaviour of the Quagga system. Here’s some output of the current configuration: # ifconfig igb0; ifconfig bridge0 igb0: flags=8943 metric 0 mtu 1500 options=6403bb ether ac:1f:6b:18:xx:6e hwaddr ac:1f:6b:18:xx:6e inet6 fe80::ae1f:6bff:fexx:66e%igb0 prefixlen 64 tentative scopeid 0x1 nd6 options=8 media: Ethernet autoselect (1000baseT ) status: active bridge0: flags=8843 metric 0 mtu 1500 description: vm-bridge0 ether 02:3c:9f:37:xx:00 inet 212.12.xx.225 netmask 0xffe0 broadcast 212.12.xx.255 inet 212.12.xx.226 netmask 0x broadcast 212.12.xx.226 inet 212.12.xx.253 netmask 0x broadcast 212.12.xx.253 inet 212.12.xx.229 netmask 0x broadcast 212.12.xx.229 inet6 fe80::3c:9fff:fe37:xx00%bridge0 prefixlen 64 scopeid 0x7 inet6 2a00:14b0:4200:32xx::1e1 prefixlen 64 inet6 2a00:14b0:4200:32xx::1e2 prefixlen 128 inet6 2a00:14b0:4200:32xx::1fd prefixlen 128 inet6 2a00:14b0:4200:32xx::1e5 prefixlen 128 nd6 options=8020 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: igb0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 200 # ndp -an Neighbor Linklayer Address Netif ExpireS Flags 2a00:14b0:4200:32xx::1e1 02:3c:9f:37:xx:00 bridge0 permanent R 2a00:14b0:4200:32xx::1 00:50:56:a1:xx:b5 bridge0 23h59m58s S R 2a00:14b0:4200:32xx::1e2 02:3c:9f:37:xx:00 bridge0 permanent R 2a00:14b0:4200:32xx::1e5 02:3c:9f:37:xx:00 bridge0 permanent R 2a00:14b0:4200:32xx::1e7 02:5a:1d:92:xx:00 bridge0 23h59m16s S 2a00:14b0:4200:32xx::1e8 02:5a:1d:92:xx:00 bridge0 23h59m2s S 2a00:14b0:4200:32xx::1eb 02:5a:1d:92:xx:00 bridge0 23h55m7s S 2a00:14b0:4200:32xx::1ea 02:5a:1d:92:xx:00 bridge0 23h2m24s S fe80::3c:9fff:fe37:2500%bridge0 02:3c:9f:37:xx:00 bridge0 permanent R fe80::250:56ff:fea1:dfb5%bridge0 00:50:56:a1:xx:b5 bridge0 23h59m57s S R 2a00:14b0:4200:32e0::1fd 02:3c:9f:37:xx:00 bridge0 permanent R fe80::ae1f:6bff:fe18:xx6f%igb1ac:1f:6b:18:xx:6f igb1 permanent R fe80::ae1f:6bff:fe18:xx6e%igb0ac:1f:6b:18:xx:6e igb0 permanent R # ndp -i bridge0 linkmtu=0, maxmtu=0, curhlim=64, basereachable=30s0ms, reachable=32s, retrans=1s0ms Flags: auto_linklocal Stefan -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP
Re: Have I got this VIMAGE setup correct?
Am 04.01.2016 um 02:33 schrieb Garrett Wollman : > > For now, I think I'll just use exec.prestart to manually configure a > MAC address. It would be nice if the LAA MAC addresses we generated > were both random on initial creation (to better avoid duplicates) and > stable over reboot. (Likewise the bridge(4) MAC address.) Or > alternatively if we just had rc.conf support for explicitly > configuring the MAC address of every interface, since ifconfig doesn't > let you configure L2 and L3 addresses on the same command line. I’ve had good experiences with using create_args_ in rc.conf. I believe that ifconfig only let’s you work with only one address family per invocation. Stefan -- Stefan BethkeFon +49 151 14070811 create_args_tap0="ether 02:00:00:00:01:00" create_args_tap1="ether 02:00:00:00:01:01" create_args_tap2="ether 02:00:00:00:01:02" create_args_tap3="ether 02:00:00:00:01:03" create_args_tap4="ether 02:00:00:00:01:04" create_args_vlan100="vlandev em0 vlan 100 up" create_args_vlan101="vlandev em0 vlan 101 up" create_args_vlan102="vlandev em0 vlan 102 up" create_args_vlan103="vlandev em0 vlan 103 up" create_args_vlan104="vlandev em0 vlan 104 up" create_args_bridge100="ether 02:00:00:00:00:64 addm vlan100" create_args_bridge101="ether 02:00:00:00:00:65 addm vlan101" create_args_bridge102="ether 02:00:00:00:00:66 addm vlan102 addm tap0 addm tap1 fib 1" create_args_bridge103="ether 02:00:00:00:00:67" create_args_bridge104="ether 02:00:00:00:00:68" ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: VirtualBox, if_bridge and bridged networking
Am 16.04.2013 um 12:13 schrieb Nicolas de Bari Embriz Garcia Rojas: > On 04/16/2013 09:31, Stefan Bethke wrote: >> Hey, >> >> I'm a bit stumped getting a (FreeBSD guest) VM to use bridged networking to >> work. The same VM works fine on a Mac OS X and an Ubuntu host, so I'm >> certain it's not the VMs setting. >> >> I'm running >> # pkg info -g virtualbox* >> virtualbox-ose-4.2.6 A general-purpose full virtualizer for x86 >> hardware >> virtualbox-ose-kmod-4.2.6_4VirtualBox kernel module for FreeBSD >> on FreeBSD 9.1-STABLE r249476 amd64. >> >> My LAN gets to the host via vlan1 (attached to re0); which in turn is >> bridged via bridge0. IP configuration is on bridge0. ... > > Try creating a tap interface and later bridge your VM to that tap. > > in your host create a bridge containing re0 and tap0. Thanks, that worked! Since I couldn't find documentation online, here's my working setup for the archives: My primary LAN comes into the host physically via re0; it's on vlan1. It is bridged via bridge0 to tap0, where it gets connected to a remote site via OpenVPN. Relevant bits from rc.conf (addresses changed): cloned_interfaces="bridge0 tap0 vlan1 vlan2 vlan3 vlan4 gif0" ifconfig_re0="up" ifconfig_vlan1="vlandev re0 vlan 1" ifconfig_bridge0="ether 02:00:00:00:00:01 addm tap0 addm vlan1" ifconfig_bridge0_alias0="inet 192.0.2.1/26" ifconfig_tap0="up" I've extended this config to include tap1, to be used for VirtualBox bridging: cloned_interfaces="bridge0 tap0 tap1 vlan1 vlan2 vlan3 vlan4 gif0" ifconfig_bridge0="ether 02:00:00:00:00:01 addm tap0 addm tap1 addm vlan1" ifconfig_bridge0_alias0="inet 192.0.2.1/26" ifconfig_re0="up" ifconfig_vlan1="vlandev re0 vlan 1" ifconfig_tap0="up" ifconfig_tap1="up" Additionally, VirtualBox needs to be able to open the tap interface. Two settings are necessary: in /etc/sysctl.conf, add: net.link.tap.user_open=1 In /etc/defvs.rules, under the rule section for your host, add: add path tap* group wheel mode 660 Then configure the VM to use tap1 for bridging: VBoxManage modifyvm FreeBSD-9-mini --bridgeadapter1 tap1 That should be it! Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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"
VirtualBox, if_bridge and bridged networking
Hey, I'm a bit stumped getting a (FreeBSD guest) VM to use bridged networking to work. The same VM works fine on a Mac OS X and an Ubuntu host, so I'm certain it's not the VMs setting. I'm running # pkg info -g virtualbox* virtualbox-ose-4.2.6 A general-purpose full virtualizer for x86 hardware virtualbox-ose-kmod-4.2.6_4VirtualBox kernel module for FreeBSD on FreeBSD 9.1-STABLE r249476 amd64. My LAN gets to the host via vlan1 (attached to re0); which in turn is bridged via bridge0. IP configuration is on bridge0. It appears that frames sent from the guest make it to the host and machines connected to the LAN, but no replies appear to be getting back to the guest. I've tried bridging the guest to bridge0 as well as vlan1. If I configure the guest's network manually, I can see arp requests arriving on the host and the LAN; inside the guest I can't see any frames arriving. If I add arp entries manually on the guest, I can see pings going out, but the replies never make it back. I am running pf, but I don't see any rejected packets of pflog0 that correlate in any way. Is there a magic configuration bit that I'm missing? Or is there some incompatibility between if_bridge and ng_ether? Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: Ethernet Switch Framework
Am 29.01.2012 um 17:19 schrieb Marius Strobl: >>> We really need >>> to find a proper way of dealing with the constraints of the embedded- >>> world rather than to sprinkle hacks all over the place. >> >> Why is the above is less of a hack than making the ordering in nexus >> configurable through a hint? >> > > If it's generally true that driver A must be attached before driver > B as B has a dependency on A than this should be expressed and > configured in the drivers themselves and not need an extra hint to > configure it at the runtime of the kernel. Except that it is not generally true, but only in specific configurations. Other boards have other combinations of devices. The Atheros family of switches is available both embedded into certain SoC as well as separate silicon. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: Ethernet Switch Framework
Am 29.01.2012 um 16:31 schrieb Marius Strobl: > How about adding the MDIO provider via multi-pass probing? That idea > of that model was to attach things like drivers for interrupt controllers > before any other driver that requires that resource. This seems like a > perfect match here and requires neither a specific hack to the nexus > (the platform generally needs to be multi-pass aware though and the > thing enabled in subr_bus.c) nor a hack to miibus(4). Please recall the devinfo graph that I posted earlier. The PHY arge0 needs to talk to is attached to the MDIO master on the switch controller, which in turn is attached to GE1's MDIO master. This would require early attachment of the switch, in turn requiring early attachment of arge_mdio, in turn requiring early attachment of mips/mips/nexus. > We really need > to find a proper way of dealing with the constraints of the embedded- > world rather than to sprinkle hacks all over the place. Why is the above is less of a hack than making the ordering in nexus configurable through a hint? Stefan -- Stefan BethkeFon +49 151 14070811 diff --git a/sys/mips/mips/nexus.c b/sys/mips/mips/nexus.c index b51357d..c4c207a 100644 --- a/sys/mips/mips/nexus.c +++ b/sys/mips/mips/nexus.c @@ -240,8 +240,11 @@ nexus_hinted_child(device_t bus, const char *dname, int dunit) int result; int irq; int mem_hints_count; + int order; - child = BUS_ADD_CHILD(bus, 0, dname, dunit); + order = 1000; /* there should be a define for the default order */ + resource_int_value(dname, dunit, "order", &order); + child = BUS_ADD_CHILD(bus, order, dname, dunit); if (child == NULL) return; ___ 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: Ethernet Switch Framework
Am 29.01.2012 um 08:05 schrieb Warner Losh: > I think that the main issue here is that we have an assumption that we have a > tree structure. However, it is more of a DAG across different domains. The > hierarchy works well when each device owns all the devices below it and only > interacted with them. Most devices are that way. However, in the embedded > world, there's lots of reach-accrosses that are expected that break the model. What do people think would be a good approach to solve the concrete issue without too much hackery? Aleksandr and I have presented three possible approaches: 1. have a PHY driver that acts as a proxy and talks to a separate MDIO master 2. have a proxy between the ethernet driver and the miibus driver 3. modify miibus to have a separate device for mediachg() etc. All three suffer from a dependency problem: miibus attachment can only complete successfully when both the ethernet driver and the mdio driver have been attached. In the current model, the ethernet driver provides both the MDIO access as well as the target for the mediachg, etc. messages, so there's no attachment ordering issue. In my miiproxy patch (2.), it is necessary for the ethernet driver to cooperate in this delayed attachment, by splitting out the miibus attachment from the device_attach method implementation. That's a fairly intrusive change, and that would need to be made to any ethernet driver that is to support such a split MDIO/MII setup. I tried delaying just the call to mii_attach(), but it seems that interacts badly with an already attached interface. Specifically, I got a non-working interface when I tried to call mii_attach() long after if_etherattach(). Additionally, if_arge (and probably most other drivers) assumes that the miibus is attached after they've successfully attached themselves, and subsequently runs into null pointer issues when it isn't. Would it be possible to attach miibus without having a working PHY, and only attach the PHYs once the MDIO device has been attached? For the mips/atheros platforms, we could introduce ordering hints for nexus to make sure the mdio driver gets attached before the arge's. That's a fairly small changes (two lines), and does work, but it's more a hack than a general solution. With my proposed change to miibus (split devices), that would bring down the necessary changes to just a handful of lines. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: Ethernet Switch Framework
Am 29.01.2012 um 13:44 schrieb Aleksandr Rybalko: >> The MII connection between the ethernet controller and the switch >> chip (usually referred to as the "CPU" port) is hard-coded and has no >> media settings, so there's no question what if_media settings should >> be presented on the interface. > > Most switches (AR8x16 for example) have configurable MII port, so you > can choose to use MII/RMII/GMII/RGMII. If you decide to use MII > media can not be higher than 100baseTX. So it is possible to use some > auto-negotiation here. The point is that the admin has no need to change it, it's hard coded in the driver or statically configured via hints. And for all of this discussion, I'm using MII as a synonym for all xMII busses. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: Ethernet Switch Framework
Am 29.01.2012 um 00:00 schrieb Juli Mallett: > On Sat, Jan 28, 2012 at 14:12, Aleksandr Rybalko wrote: >> As I see from your patch, mdio/miiproxy require special bits in MAC >> driver. When I design switch framework, I keeping in mind that >> MAC drivers should be standard as possible > > I don't understand why this is desirable in practice. It's a nice > theory, but it falls down when one thinks in depth about how Ethernet > interfaces are used and administered vs. how switches are used and > administered. What should media report? What should media changes > do? What is link status? Do you show the CPU-to-switch port, or all > switch ports? The main thrust here is to reuse the existing PHY code to be able to configure the PHYs that are embedded in the switch chips. To confuse things, one of these PHYs might be connected to the SoCs ethernet interface via MII, GMII, etc. To confuse things further, these PHYs are controlled by an MDIO bus that has it's master in the switch chip, while the switch chip is a slave to the MDIO master in the ethernet controller. The goal is to be able to configure the switch ports and set media on one of them, for example. That code path could be entirely independent from the ethernet infrastructure, if dev/miibus didn't require if_media and hence a struct ifnet. This discussion is also about how to deal with this entanglement. The MII connection between the ethernet controller and the switch chip (usually referred to as the "CPU" port) is hard-coded and has no media settings, so there's no question what if_media settings should be presented on the interface. > are a lot of switches out there that don't look or act much like > MII-driven PHYs, but which are connected over MDIO, as I've tried to > stress before. I hope there will be as much separation between the > MII work that is being done and the switch work that is being done as > possible. I think anything else will prove rapidly-obsolete and > perhaps even obstructive as soon as anyone seeks to add support for > more switch chipsets to FreeBSD. > > I suppose the most likely reality, though, is that people simply won't > add switch support to FreeBSD, and will administer them out-of-band > from userland, using gross kernel shims. That is probably true > whether any of the currently-outstanding work is committed or not, > unfortunately :( I just hope we'll end up with something flexible > enough, broad enough in applicability, narrow enough in requirements, > etc., that we'll have feature-rich support for a few chipsets in tree > that work in sufficiently-different manners that they can be models > for other drivers in the future. Which is a valid approach from a vendor's viewpoint. The reason we're talking is to try and make it easier to write a switch driver for this framework than roll your own hack. :-) Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: Ethernet Switch Framework
Am 25.01.2012 um 08:12 schrieb Adrian Chadd: > So when will you two have something consensus-y to commit? :-) > > What I'm hoping for is: > > * some traction on the MII bus / MDIO bus split and tidyup from stb, which is > nice; > * ray's switch API for speaking to userland with; > * agreeing on whether the correct place to put the driver(s) is where stb, > ray, or a mix of both approaches says so. > > I've been (mostly) trying to stay out of this to see where both of you have > gone. I think we've made some good progress; now it's time to solidify a > design for the first pass of what we want in -HEAD and figure out how to move > forward. My suggestion is to take my bus attachment code (incl. mdio and miiproxy) and ray's ioctl and userland code. Aleksandr's approach for the driver attachment is to have a generic switch "bus" driver that abstracts the mii, i2c, memory mapped I/O, etc. busses the devices are physically attached to, and present a uniform register file to the chip-specific switch driver. I believe that this is unnecessarily complicated for two reasons: newbus already provides that abstraction, and chip-specific drivers usually differ in so many aspects, including their register files, that code sharing between chips will be somewhat limited anyway. One aspect that I would enjoy looking into in more detail is how register accesses on, for example, MDIO, can be provided through the bus space API. From my cursory reading, it seems that the code currently is tailored towards register accesses that can be implemented through CPU native instructions, instead of indirectly through a controller. Aleksandr has defined a quite comprehensive ethernet switch control API that the framework provides towards in-kernel clients as well as userland. I think it would be really helpful if we could concentrate on those API functions that can be controlled through the userland utility, have immediate use cases (for example, VLAN configuration on the TL-WR1043ND to separate the WAN from the LAN ports), and we have test hardware for. In short, don't commit dead code. Having a description of the generic switch model that the API assumes and driver-specific documentation also wouldn't hurt. (Yes, I'm volunteering.) Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: Ethernet Switch Framework
?) ra c3f599a80020 sp 0 sz 0
witness_checkorder+9cc (?,?,803b1f7c,877) ra c3f599c80050 sp 0 sz 1
__lockmgr_args+948 (?,?,80956eb4,?) ra c3f59a180070 sp 0 sz 1
vop_stdlock+4c (?,?,?,?) ra c3f59a880028 sp 0 sz 0
VOP_LOCK1_APV+e4 (?,?,?,?) ra c3f59ab00020 sp 0 sz 0
_vn_lock+84 (?,?,?,?) ra c3f59ad00048 sp 0 sz 0
vget+c8 (?,?,?,?) ra c3f59b180030 sp 0 sz 0
devfs_allocv+100 (?,?,?,?) ra c3f59b480038 sp 0 sz 0
800ba9b4+4c (?,?,?,?) ra c3f59b800028 sp 0 sz 0
vflush+6c (?,?,0,80991300) ra c3f59ba800f8 sp 0 sz 1
800baa74+54 (?,?,?,?) ra c3f59ca00028 sp 0 sz 0
dounmount+3f0 (809e8000,?,?,?) ra c3f59cc80050 sp 1 sz 0
sys_unmount+39c (?,?,?,?) ra c3f59d1800b0 sp 0 sz 0
trap+7f4 (?,?,?,?) ra c3f59dc800b8 sp 0 sz 0
MipsUserGenException+10c (?,?,?,404b53c0) ra c3f59e80 sp 0 sz 0
pid 70
Mounting local file systems:.
Setting hostname: whitebox.lassitu.de.
miibus0: mii_mediachg: can't handle non-zero PHY instance 1
floatphy0: found master switch0
miibus0: mii_mediachg: can't handle non-zero PHY instance 1
arge0: link state changed to DOWN
Starting Network: lo0 arge0 arge1.
lo0: flags=8049 metric 0 mtu 16384
options=3
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff00
nd6 options=21
arge0: flags=8843 metric 0 mtu 1500
options=8
ether ff:ff:ff:ff:ff:ff
inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
inet6 fe80::481f:1b46:dbf1:bd78%arge0 prefixlen 64 scopeid 0x2
nd6 options=29
media: Ethernet autoselect (100baseTX )
status: no carrier
arge1: flags=8843 metric 0 mtu 1500
ether ff:ff:ff:ff:ff:00
inet 44.128.65.33 netmask 0xffc0 broadcast 44.128.65.63
inet6 fe80::481f:1b46:dbf1:bd78%arge1 prefixlen 64 scopeid 0x3
nd6 options=29
media: Ethernet 100baseTX
status: active
add net default: gateway 44.128.65.1
add net :::0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
add net fe80::: gateway ::1
add net ff02::: gateway ::1
Mounting NFS file systems:mount_nfs: diesel: hostname nor servname provided, or
not known
.
Creating and/or trimming log files.
No core dumps found.
ELF ldconfig path: /lib /usr/lib /usr/lib/compat
Setting date via ntp.
Error : hostname nor servname provided, or not known
22 Jan 15:01:04 ntpdate[566]: can't find host diesel
22 Jan 15:01:04 ntpdate[566]: no servers can be used, exiting
Clearing /tmp (X related).
Mounting late file systems:mount_nfs: diesel: hostname nor servname provided,
or not known
.
Mounting /etc/fstab filesystems failed,Jan 22 15:01:12 init: /bin/sh on /etc/rc
terminated abnormally, going to single user mode
Enter full pathname of shell or RETURN for /bin/sh:
# devinfo
nexus0
clock0
apb0
uart0
gpio0
gpioc0
gpiobus0
gpioled0
gpioled1
gpioled2
ehci0
usbus0
uhub0
umass0
arge0
miibus0
floatphy0
switch0
ar8x16_switch0
arge1
spi0
spibus0
mx25l0
ar71xx_wdog0
#
--
Stefan BethkeFon +49 151 14070811
___
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: "ifconfig media off"?
Am 14.12.2011 um 02:16 schrieb Marius Strobl:
> On Tue, Dec 13, 2011 at 10:53:48AM -0800, YongHyeon PYUN wrote:
>> On Tue, Dec 13, 2011 at 11:04:51AM +0100, Stefan Bethke wrote:
>>> Am 13.12.2011 um 03:50 schrieb YongHyeon PYUN:
>>>
>>>> On Tue, Dec 13, 2011 at 12:56:22AM +0100, Stefan Bethke wrote:
>>>>> I'm currently writing a driver to configure an ethernet switch chip (see
>>>>> TL-WR1043ND on -embedded).
>>>>>
>>>>> I noticed that there doesn't seem to be a way to power down a phy right
>>>>> now through the ifconfig media command.
>>>>>
>>>>> Would there be objections to extend the media subtype definitions to
>>>>> include an "off", "poweroff" or "down" media subtype, and add code to the
>>>>> relevant phy drivers to power down the phy for this media subtype?
>>>>>
>>>>> The difference between media subtype "none" and this new one would be
>>>>> that there will be no link, even if there is a physical connection. With
>>>>> media subtype "none", a 10 MBit/s half-duplex connection is established,
>>>>> potentially confusing the remote end about the availability of this link.
>>>>> On the local side, the link is down, so no packets are exchanged.
>>>>>
>>>>
>>>> I think "none" means "isolated" so should have no established link
>>>> and probably you can also power down the PHY.
>>>> I vaguely guess the PHY of switch chip does not correctly support
>>>> isolated mode so you may have wanted to power down.
>>>
>>>
>>> After looking at the code a bit more, I think the common code just doesn't
>>> set the BMCR_PDOWN (but clears it when bringing up the PHY).
>>>
>>
>> Yes, and most PHYs could be powered down when BMCR_ISO is chosen.
>> I'm not sure whether this could be applied to hardwares that
>> support multiple PHYs(i.e. internal and external transceivers)
>> though. Marius may have some opinions on this(CCed).
>> However powering down PHY with BMCR_ISO looks natural to me.
>>
>>> Index: sys/dev/mii/mii_physubr.c
>>> ===
>>> --- sys/dev/mii/mii_physubr.c (revision 228402)
>>> +++ sys/dev/mii/mii_physubr.c (working copy)
>>> @@ -58,7 +58,7 @@
>>> */
>>> static const struct mii_media mii_media_table[MII_NMEDIA] = {
>>> /* None */
>>> - { BMCR_ISO, ANAR_CSMA,
>>> + { BMCR_ISO | BMCR_PDOWN,ANAR_CSMA,
>>> 0, },
>>>
>>> /* 10baseT */
>>>
>>> I've opened kern/163240.
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=163240
I'd like to revisit this. Just to reiterate my motivation for the change: I
want to be able to indicate to the remote end that my station is not active.
With the PHY just isolated from the MII, the link stays up and functional (and
even autoneg continues to work), so the remote has no indication that it's just
shouting into a void.
> I don't think powering down the PHY along with IFM_NONE especially
> in that way is a good idea for several reasons:
> - It's incomplete as not all PHY drivers use mii_phy_add_media()/
> mii_phy_setmedia().
> - Even for those that do IFM_NONE isn't added when the PHY driver
> sets MIIF_NOISOLATE (for some PHYs BMCR_ISO either just doesn't
> work as especially the built-in ones probably have been designed
> with only single-PHY configurations in mind or even wedges the
> chip up to the point that even a reset doesn't get it working
> again). In general though, BMCR_ISO and BMCR_PDOWN are orthogonal
> (even in IEEE 802.3-2008 as far as I can see), i.e. while BMCR_ISO
> might be broken, BMCR_PDOWN could work (actually I'd expect
> BMCR_PDOWN to be less fragile than BMCR_ISO).
I didn't expect my suggestion to be the be-all end-all, only a quick and easy
way to allow compliant PHYs to be powered down, and I'm not sure why a
"complete" solution is required. I'd assume that PHYs setting MIIF_NOISOLATE
have specific requirements, so it's OK to not have the power-down option
available there. (Plus I don't have hardware I could test that case on).
> - There should be a way to let a PHY driver do something different
> than setting BMCR_PDOWN when it's told to power down as f.e. at
> least some Broadcom PHYs support a "super isol
Re: Ethernet Switch Framework
Thank you for the update, that clears up a number of questions I had. Here's a couple of questions and comments. Which devices can this code be run on? For example, can the AR7240 config run on an TL-WR3420? Would you mind giving an overview of how the various parts fit together, how they are probed and attached? I think I understand from you explanations on IRC, but not everbody had that chance. Am 20.01.2012 um 21:13 schrieb Aleksandr Rybalko: > get/set reg: > Generic access to registers. Have 2 address modifiers: > 0x(no modifiers) - access to parent space (parent MDIO bus, if > switchX attaches to miibusX) > 0x4000 - access to switch MDIO bus > 0x8000 - access to switch registers. Wouldn't it be better to have a proper API to select the various busses and device register files? > FloatPHY > pseudo driver which attach to miibus like normal PHY, but do find > master switchX device and ask his PHY reg's. Main problem with that > driver - is usage of newbus calls between independent device (not a > parent <-> child), since floatphyX query set/get methods of switchX. The general approach has a number of problems, as far as I understand the miibus code. miibus assumes that only one of the PHYs on the MII is active concurrently (since that's a requirement of the MII/GMII/... bus). If I read your code correctly, you have one miibus that has all the PHYs for all switch ports on them. Won't miibus just isolate all but one PHY? In your current implementation, you've reimplented ukphy (in a limited fashion). One of the advantages of reusing the mii framework is being able to use all the PHYs, in case a switch chip would include a quirky PHY. Extending floatphy to work as a full proxy for any phy driver looks non-trivial to me due to the API constraints the mii framework imposes. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: "float PHYs", communication between indirect attached devices
Am 02.01.2012 um 22:32 schrieb Adrian Chadd: > Hi, > > How about ray (or stefan, or someone :) does up a bit of a summary as > to how zrouter uses the floatphy and other stuff in the configuration > hints to represent all of this? > > Would we be better off changing the miibus code to work with the > notion of non-phy devices? Would that help a bit? If you wouldn't mind waiting a day or two, I'm working on a suggestion. First draft RSN… Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: "float PHYs", communication between indirect attached devices
Am 10.12.2011 um 13:05 schrieb Aleksandr Rybalko: > Hi net@ subscribers, > > Simple explanation of problem: > real situation, device with two NICs (arge0 and arge1) > arge0 attached to PHY w/o direct access to it. > arge1 attached to switch MII port (and have access to MDIO bus). > > switch have child MDIO bus for all Physical ports. > One of this ports (or his PHY) must be controlled by arge0. > > I will do pseudo PHY driver that must communicate with real one on > switch MDIO bus. > > Question: how to communicate, since newbus can't handle two parents: > 1) sysctl > 2) events > 3) kenv > 4) something better > globals is not a solution, because it is possible that we will have > some device with more than one "float PHYs" > > please, help me to find best way! > > Wait for your suggestions, comments, hints, etc. I'll trx to explain with a bit more detail what the situation is, and what variations we're encountering with the various embedded systems that have a switch connected to one or more ethernet ports of the SoC. Right now Adrian, Aleksadr and I are trying to add configuration support for the switch controllers in small WLAN routers based on the various Atheros SoC and a variety of switch controllers. As different as they might be, they are usually attached in one of these ways: - the ethernet interface is connected via MII, RGMII or GMII to one of the MACs on the switch (back to back, no PHY). The switch might have PHYs attached to its other ports, but as far as the SoC ethernet interfaces are concerned, there's nothing to be configured. - the interface is connected to a PHY via MII, but the PHYs MDIO slave is not connected to the ethernet interface's MDIO master. Both can exist at the same time; e.g in many wlan routers, arge0 is connected to a PHY in the switch chip, while arge1 is connected to one of the switch port MACs. The switch controller can be connected to the SoC via I2C (e.g. RTL83XX series), or through an MDIO interface (AR8x16, RTL830x). The switch controller has its own MDIO master, controlled through the switch register set, to communicate with the built-in PHYs. To further confuse things: the PHY that arge0 is connected to can only be controlled by talking to the switch that is connected to arge1's MDIO master, in turn talking to the switch's MDIO master to talk to the PHY. This poses a number of challenges: - ethernet switches that are attached via MDIO may not look like PHYs, in particular, they might not have a BMSR or ID1 and ID2. This is the case with the Atheros AR8x16 series. The miibus code assumes that all possible children of an miibus are PHYs, and will not easily accept non-PHY children. - attach hierarchy and sequence, e.g. for the PHY in the switch chip, where the switch chip is attached to arge1, but the PHY needs to be at arge0. - creating miibus'ses that are not associated with an interface. The miibus code assumes that any PHY is attached to an MII connected to an ethernet interfaces MAC. The switch ports are not part of the ethernet interfaces, and their MAC configuration doesn't change when one of the switch ports negotiate a different media setting. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: "ifconfig media off"?
Am 13.12.2011 um 03:50 schrieb YongHyeon PYUN:
> On Tue, Dec 13, 2011 at 12:56:22AM +0100, Stefan Bethke wrote:
>> I'm currently writing a driver to configure an ethernet switch chip (see
>> TL-WR1043ND on -embedded).
>>
>> I noticed that there doesn't seem to be a way to power down a phy right now
>> through the ifconfig media command.
>>
>> Would there be objections to extend the media subtype definitions to include
>> an "off", "poweroff" or "down" media subtype, and add code to the relevant
>> phy drivers to power down the phy for this media subtype?
>>
>> The difference between media subtype "none" and this new one would be that
>> there will be no link, even if there is a physical connection. With media
>> subtype "none", a 10 MBit/s half-duplex connection is established,
>> potentially confusing the remote end about the availability of this link.
>> On the local side, the link is down, so no packets are exchanged.
>>
>
> I think "none" means "isolated" so should have no established link
> and probably you can also power down the PHY.
> I vaguely guess the PHY of switch chip does not correctly support
> isolated mode so you may have wanted to power down.
After looking at the code a bit more, I think the common code just doesn't set
the BMCR_PDOWN (but clears it when bringing up the PHY).
Index: sys/dev/mii/mii_physubr.c
===
--- sys/dev/mii/mii_physubr.c (revision 228402)
+++ sys/dev/mii/mii_physubr.c (working copy)
@@ -58,7 +58,7 @@
*/
static const struct mii_media mii_media_table[MII_NMEDIA] = {
/* None */
- { BMCR_ISO, ANAR_CSMA,
+ { BMCR_ISO | BMCR_PDOWN,ANAR_CSMA,
0, },
/* 10baseT */
I've opened kern/163240.
http://www.freebsd.org/cgi/query-pr.cgi?pr=163240
Stefan
--
Stefan BethkeFon +49 151 14070811
___
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"
"ifconfig media off"?
I'm currently writing a driver to configure an ethernet switch chip (see TL-WR1043ND on -embedded). I noticed that there doesn't seem to be a way to power down a phy right now through the ifconfig media command. Would there be objections to extend the media subtype definitions to include an "off", "poweroff" or "down" media subtype, and add code to the relevant phy drivers to power down the phy for this media subtype? The difference between media subtype "none" and this new one would be that there will be no link, even if there is a physical connection. With media subtype "none", a 10 MBit/s half-duplex connection is established, potentially confusing the remote end about the availability of this link. On the local side, the link is down, so no packets are exchanged. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: bridged wlan/ether still the same
Am 02.04.2010 um 09:45 schrieb Randy Bush: > it's the bridge that worries me. took me a while to make it work It looks sane to me. Here's my slightly more convoluted setup (8-stable): cloned_interfaces="bridge0 tap0 vlan1 vlan2 vlan3 gif0" ifconfig_bridge0="ether 02:00:00:00:00:01 addm tap0 addm vlan1" ifconfig_bridge0_alias0="inet 44.128.65.1/26" ifconfig_em0="up" ifconfig_vlan1="vlandev em0 vlan 1" ifconfig_vlan2="44.128.65.249/29 vlandev em0 vlan 2" ifconfig_vlan3="172.23.54.1/24 vlandev em0 vlan 3" ifconfig_tap0="up" I've set bridge0's MAC address to avoid sillyness with a cheap desktop switch that would get confused on reboots. HTH, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: Running rtadvd or DHCPv6 server via if_bridge interface
Am 11.12.2009 um 07:51 schrieb Chris Cowart: > Bruce Cran wrote: >> I have a router configured using if_bridge with a 4-port NIC that's >> serving addresses over DHCP. I'd like to add in either rtadvd or >> DHCPv6, but neither work because the bridge interface doesn't have an >> IPv6 link-local address. Is there a way around this, or is it not >> possible to serve IPv6 addresses over if_bridge interfaces? > > It's totally doable; you just have to assigned a link-local address to > the bridge. There are some reasons why one isn't defined by default, > which somebody more knowledgeable about the challenges in the > implementation can highlight. > > Here's my configuration from rc.conf: > > ipv6_ifconfig_bridge0="2001:470:8337:10::1/64" > ipv6_ifconfig_bridge0_alias0="fe80::2%bridge0 prefixlen 64" > > Once you're doing that, rtadvd will start doing the right thing. I've just stumbled over this the first time. I thought that best practice nowadays was to use the bridge interface for host communications, and leaving the physical interfaces unconfigured, so I'm a bit confused why if_bridge would not allow the auto-assignment of a link-local address. If you have two or more bridged interfaces now, and you enable automatic assignment of link-local addresses, you already have multiple link-locals this way; having the bridge have one as well wouldn't make things worse (I think). Slightly confused, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: change in ifconfig out put for wlan devices on -CURRENT
Am 20.03.2009 um 19:51 schrieb Kevin Downey: I did not notice a heads up about this, but recently (maybe in the last few weeks?) wlan devices on -CURRENT no longer show information like what ssid they are associated with. How can I find this information now? this what the current output looks like: wlan0: flags=8843 metric 0 mtu 1500 ether 00:1d:7d:78:2a:69 inet6 fe80::21d:7dff:fe78:2a69%wlan0 prefixlen 64 scopeid 0x4 inet 192.168.0.197 netmask 0xff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet OFDM/48Mbps mode 11g status: associated Maybe it's the same issue as in this thread? <http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004813.html > HTH, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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"
if_bridge and .1q VLANs
Hi there, it appears if_bridge bridges tagged frames alongside non-tagged frames. Is there a way to either stop if_bridge from doing so, or otherwise filtering out the tagged frames? My trunk currently has one untagged network and two tagged VLANs on it (the untagged one being the main LAN), and I'm bridging the LAN to another site via OpenVPN. But I'd rather not bridge the other two VLANs, if at all possible. I can switch the untagged VLAN to tagged on the switch, if that turns out to be the easiest option, and bridge between tap and another vlan interface. Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: Multi-homing, jails, and source address selection
Am 14.03.2009 um 22:35 schrieb Julian Elischer:
Stefan Bethke wrote:
Am 14.03.2009 um 19:01 schrieb Bjoern A. Zeeb:
On Thu, 12 Mar 2009, Stefan Bethke wrote:
I'm having some trouble configuring a dual-homed jail host,
running -current from about 4 weeks ago.
...
Is there any documentation on how source addresses are selected?
I thought I remembered that on unbound sockets the destination
route would be used to pick the first address of the outgoing
interface as the source address; the same address would be picked
on connecting a socket.
sys/netinet/in_pcb.c:in_pcbladdr() is your friend -
http://fxr.watson.org/fxr/source/netinet/in_pcb.c#L546
This is the case you are running into:
http://fxr.watson.org/fxr/source/netinet/in_pcb.c#L628
/*
* If the outgoing interface on the route found is not
* a loopback interface, use the address from that interface.
* In case of jails do those three steps:
* 1. check if the interface address belongs to the jail. If so use
it.
* 2. check if we have any address on the outgoing interface
*belonging to this jail. If so use it.
* 3. as a last resort return the 'default' jail address.
*/
so you are hitting "3." .
I am not sure but I'd assume
ifconfig tun0 10.0.63.3 10.0.63.255 alias
would work, just not with the logic to create the IPs upon jail
start
(and we will not accept patches to handle that;).
This is what I figured is happening.
For the time being, I've gone back to single-homed; I'm using pf
binat rules to map public ips to the vpn ones for the jails. Not
perfect, but works for most cases. (The only really missing option
is to bind a service in the jail to VPN address only, so it's only
accessible over the VPN, but I can enforce that through pf or
hosts.allow.)
Assigning aliases to tun0 appears to work too, but you need a
distinct destination address for each alias. Annoying.
Since I'm using "topology subnet" in OpenVPN, a point-to-point
interface is conceptually slightly off; a broadcast interface would
fit much nicer. This would also allow the standard rc.d/jail
script to do it's magic, if the necessary tun seetings could be
applied through ifconfig. Is there a specific reason this setting
can only be done through an ioctl on the dev node, instead of
thorugh ifconfig? (Specifically TUNSIFMODE.)
Additionally, this open the way to run OpenVPN inside a jail, since
all ifconfig and route setup would be done prior to OpenVPN
starting up. (tun also down the interface if the dev node is
closed, but I have a feeling that could be mediated somewhat easily
as well.)
One of the things you can do is assign different routing tabels to
each jail. This means that tho can control which interface it will
select as the outgoing interface.
setfib -{0-15} jail (jail args)
I hope to investigate the VIMAGE work soon, but how exactly would that
help me with multihoming jails? As it turns out, my issue is with
source address selection mostly, and the way point-to-point interfaces
work; the routing table doesn't really come into play?
Stefan
--
Stefan BethkeFon +49 151 14070811
___
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: Multi-homing, jails, and source address selection
Am 14.03.2009 um 19:01 schrieb Bjoern A. Zeeb: On Thu, 12 Mar 2009, Stefan Bethke wrote: I'm having some trouble configuring a dual-homed jail host, running -current from about 4 weeks ago. ... Is there any documentation on how source addresses are selected? I thought I remembered that on unbound sockets the destination route would be used to pick the first address of the outgoing interface as the source address; the same address would be picked on connecting a socket. sys/netinet/in_pcb.c:in_pcbladdr() is your friend - http://fxr.watson.org/fxr/source/netinet/in_pcb.c#L546 This is the case you are running into: http://fxr.watson.org/fxr/source/netinet/in_pcb.c#L628 /* * If the outgoing interface on the route found is not * a loopback interface, use the address from that interface. * In case of jails do those three steps: * 1. check if the interface address belongs to the jail. If so use it. * 2. check if we have any address on the outgoing interface *belonging to this jail. If so use it. * 3. as a last resort return the 'default' jail address. */ so you are hitting "3." . I am not sure but I'd assume ifconfig tun0 10.0.63.3 10.0.63.255 alias would work, just not with the logic to create the IPs upon jail start (and we will not accept patches to handle that;). This is what I figured is happening. For the time being, I've gone back to single-homed; I'm using pf binat rules to map public ips to the vpn ones for the jails. Not perfect, but works for most cases. (The only really missing option is to bind a service in the jail to VPN address only, so it's only accessible over the VPN, but I can enforce that through pf or hosts.allow.) Assigning aliases to tun0 appears to work too, but you need a distinct destination address for each alias. Annoying. Since I'm using "topology subnet" in OpenVPN, a point-to-point interface is conceptually slightly off; a broadcast interface would fit much nicer. This would also allow the standard rc.d/jail script to do it's magic, if the necessary tun seetings could be applied through ifconfig. Is there a specific reason this setting can only be done through an ioctl on the dev node, instead of thorugh ifconfig? (Specifically TUNSIFMODE.) Additionally, this open the way to run OpenVPN inside a jail, since all ifconfig and route setup would be done prior to OpenVPN starting up. (tun also down the interface if the dev node is closed, but I have a feeling that could be mediated somewhat easily as well.) Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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"
Multi-homing, jails, and source address selection
I'm having some trouble configuring a dual-homed jail host, running - current from about 4 weeks ago. My machine has one external interface em0 connected to an /27 IPv4 network. Additionally, I have a VPN interface tun0 provided by an OpenVPN instance with a private /18 range. I'd like my jails to be dual-homed, with a public and a VPN address each. Processes in the jail should pick the appropriate source address depending on the destination address, so that the source address for a connection going to a VPN address will be the jails' VPN address, and all other connections will use the jails' public IP. I have a couple of questions that I can't seem to find answers to: How do I get the VPN addresses configured? tun0 won't accept them (since ptp interfaces require a destination address). If I use lo0, I seem to have source address selection issues. I've experimented with various setups, but haven't found one that would work just right. In the example below, if I ping from foo to a VPN address, the source address is foo's public IP. If I run ping with -S10.0.63.3, the source address still is 192.0.2.3. Is there any documentation on how source addresses are selected? I thought I remembered that on unbound sockets the destination route would be used to pick the first address of the outgoing interface as the source address; the same address would be picked on connecting a socket. I'm currently running with this configuration in rc.conf: cloned_interfaces="tun0" ifconfig_em0="192.0.2.2/27" ifconfig_tun0="10.0.63.1 10.0.63.255" defaultrouter="192.0.2.1" inetd_flags="-wW -a 192.0.2.2" static_routes="openvpn" route_openvpn="10.0.0.0/18 10.0.63.255" jail_enable="YES" jail_set_hostname_allow="NO" jail_sysvipc_allow="YES" jail_devfs_enable="YES" jail_mount_enable="YES" jail_list="foo bar baz" jail_foo_rootdir="/jail/foo.example.com" jail_foo_hostname="foo.example.com" jail_foo_ip="em0|192.0.2.3,lo0|10.0.63.3" Any suggestions? -- Stefan BethkeFon +49 151 14070811 ___ 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: Gateway problem
Am 20.10.2006 um 20:42 schrieb Brian Hawk: tun0 and ADSL is the default gateway. But the TCP packets are bound to 212.64.212.180 IP address which should send them out thru xl1. But it doesn't. That is correct. The routing table will only consider the destination address when deciding which route (and thereby which interface) a packet should traverse. You will need to use IPFW, pf, or similiar to force packets originating on your xl0's address (212.64.212.180) to go to the router on that network instead of to the default routes gateway/ interface. Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Two ISP connections with Natd
Am 04.09.2006 um 12:40 schrieb David Bila: I am running freebsd as getway for my office. I Just acquired second Internet last week. I wonder if there is a way trhough route add - net and ipfw I can manipulate my traffic in a such way that some traffic to a selected network can go through one ISP while the rest goes through the default gateway. I am using natd and my FreeBSD box has got 3 NICs, one for internal network and other two for each ISP. The short answer: yes, it is possible to configure ipfw (or pf) to route some connections over ISP A and others over ISP B. If you want more specific hints, you should give us more details: how are those two ISPs connected to your FreeBSD machine? Direct IP network, PPPoE? Which connections specifically do you want routed through which ISP? Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/102607: [if_bridge] don't generate random L2 address
The following reply was made to PR kern/102607; it has been noted by GNATS. From: Stefan Bethke <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], Radim Kolar <[EMAIL PROTECTED]> Cc: Subject: Re: kern/102607: [if_bridge] don't generate random L2 address Date: Sun, 3 Sep 2006 13:40:05 +0200 The example obviously should read ifconfig_bridge0="link 12:34:56:78:9a:bc addm em0 addm em1 DHCP" Thanks Radim for pointing this out. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/102607: [if_bridge] don't generate random L2 address
The following reply was made to PR kern/102607; it has been noted by GNATS. From: Stefan Bethke <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: kern/102607: [if_bridge] don't generate random L2 address Date: Sun, 3 Sep 2006 01:09:16 +0200 Here's my suggestion for an addition to if_bridge(4): --- if_bridge.4.origSun Aug 13 20:44:18 2006 +++ if_bridge.4 Fri Sep 1 18:53:19 2006 @@ -107,6 +107,13 @@ in .Xr rc.conf 5 . .Pp +The +.Nm +interface randomly chooses a link (MAC) address in the range reserved for +locally adminstered addresses when it is created. +The address can be changed by assigning the desired link address using +.Xr ifconfig 8 . +.Pp The MTU of the first member interface to be added is used as the bridge MTU. All additional members are required to have exactly the same value. .Pp @@ -231,6 +238,16 @@ addm fxp6 stp fxp6 \e addm fxp7 stp fxp7 \e up +.Ed +.Pp +The bridge can be used as a regular host interface at the same time as +bridging between it's member ports. In this example, the bridge connects em0 +and em1, and will receive it's IP address through DHCP: +.Bd -literal -offset indent +cloned_interfaces="bridge0" +ifconfig_bridge0="link 12:34:56:78:9a:bc addm em0 addm em0 DHCP" +ifconfig_em0="up" +ifconfig_em1="up" .Ed .Pp The bridge can tunnel Ethernet across an IP internet using the EtherIP ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/102607: [if_bridge] don't generate random L2 address
Here's my suggestion for an addition to if_bridge(4): --- if_bridge.4.origSun Aug 13 20:44:18 2006 +++ if_bridge.4 Fri Sep 1 18:53:19 2006 @@ -107,6 +107,13 @@ in .Xr rc.conf 5 . .Pp +The +.Nm +interface randomly chooses a link (MAC) address in the range reserved for +locally adminstered addresses when it is created. +The address can be changed by assigning the desired link address using +.Xr ifconfig 8 . +.Pp The MTU of the first member interface to be added is used as the bridge MTU. All additional members are required to have exactly the same value. .Pp @@ -231,6 +238,16 @@ addm fxp6 stp fxp6 \e addm fxp7 stp fxp7 \e up +.Ed +.Pp +The bridge can be used as a regular host interface at the same time as +bridging between it's member ports. In this example, the bridge connects em0 +and em1, and will receive it's IP address through DHCP: +.Bd -literal -offset indent +cloned_interfaces="bridge0" +ifconfig_bridge0="link 12:34:56:78:9a:bc addm em0 addm em0 DHCP" +ifconfig_em0="up" +ifconfig_em1="up" .Ed .Pp The bridge can tunnel Ethernet across an IP internet using the EtherIP -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/102607: [if_bridge] don't generate random L2 address
Am 28.08.2006 um 18:19 schrieb Andrew Thompson: Pass over to freebsd-net for discussion on the best way to handle this. http://www.freebsd.org/cgi/query-pr.cgi?pr=102607 From the PR: 1. change kernel code or to generate static IP address for bridge interface from attached member interfaces. or 2. use startup scripts to generate random number and store it somewhere in /var. or 3. Make system complain/warning if you set bridge0 to broadcast address. or 4. Document in if_bridge(4) that L2 address is random and document correct format of ethernet addresses. Problem with 1. is that address will change if you add or swap NICs in bridge, but it is still less likely to change than using random numbers now. First, the actual behavior and it's implications should be documented in if_bridge(4), specifically the random assignment of a locally administered address. (Cf. net/if_bridge.c:bridge_clone_create()) If the user wants a different (fixed) address on the bridge, I think it's acceptable to configure this in rc.conf along with the member interfaces. (Already implemented: ifconfig_bridge0="create ether 01:23:45:67:89:ab...") In general, ifconfig should at least warn if you try to assign an invalid MAC address to an interface. It probably wouldn't hurt to add a section about ethernet addresses to the ifconfig man page, explaining valid choices for LAAs. (I'll try to put together something over the weekend.) My 0,02 EUR, Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ppp(8) / ng_pppoe: choked output queue?
Hi, just found my router being unable to reestablish the PPPoE connection this morning. This had been going on for about four hours before I restarted ppp. Any ideas what would cause the output queue to choke, why it would report Already in NETWORK phase, why the output queue is choking, and why ppp can't successfully clear it? Aug 24 05:52:32 diesel ppp[330]: Phase: deflink: Connected! Aug 24 05:52:32 diesel ppp[330]: Phase: deflink: opening -> dial Aug 24 05:52:32 diesel ppp[330]: Phase: deflink: dial -> carrier Aug 24 05:52:33 diesel ppp[330]: Phase: Received NGM_PPPOE_ACNAME (hook "HN-XDSL") Aug 24 05:52:33 diesel ppp[330]: Phase: Received NGM_PPPOE_SESSIONID Aug 24 05:52:33 diesel ppp[330]: Phase: Received NGM_PPPOE_SUCCESS Aug 24 05:52:33 diesel ppp[330]: Phase: deflink: carrier -> login Aug 24 05:52:33 diesel ppp[330]: Phase: deflink: login -> lcp Aug 24 05:52:34 diesel ppp[330]: Phase: deflink: his = CHAP 0x05, mine = none Aug 24 05:52:34 diesel ppp[330]: Phase: Chap Input: CHALLENGE (24 bytes from BRUN-0176-03-11) Aug 24 05:52:34 diesel ppp[330]: Phase: Chap Output: RESPONSE (04022758623) Aug 24 05:52:34 diesel ppp[330]: Phase: Chap Input: SUCCESS Aug 24 05:52:34 diesel ppp[330]: Phase: deflink: Already in NETWORK phase Aug 24 05:52:34 diesel ppp[330]: Phase: deflink: lcp -> open Aug 24 05:52:39 diesel ppp[330]: Phase: Clearing choked output queue Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: open -> lcp Aug 24 05:54:34 diesel ppp[330]: Phase: Received NGM_PPPOE_CLOSE Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: Device disconnected Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: Disconnected! Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: lcp -> logout Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: Disconnected! Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: logout -> hangup Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: Connect time: 122 secs: 841 octets in, 533 octets out Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: 985248 packets in, 622067 packets out Aug 24 05:54:34 diesel ppp[330]: Phase: total 11 bytes/sec, peak 61 bytes/sec on Thu Aug 24 05:52:35 2006 Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: hangup -> opening Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: Enter pause (15) for redialing. Aug 24 05:54:39 diesel ppp[330]: Phase: Clearing choked output queue Here's the successful connection from by restarting ppp: Aug 24 06:11:08 diesel ppp[91689]: Phase: Using interface: tun0 Aug 24 06:11:08 diesel ppp[91689]: Phase: deflink: Created in closed state Aug 24 06:11:08 diesel ppp[91690]: Phase: PPP Started (ddial mode). Aug 24 06:11:08 diesel ppp[91690]: Phase: bundle: Establish Aug 24 06:11:08 diesel ppp[91690]: Phase: deflink: closed -> opening Aug 24 06:11:08 diesel ppp[91690]: Phase: deflink: Connected! Aug 24 06:11:08 diesel ppp[91690]: Phase: deflink: opening -> dial Aug 24 06:11:08 diesel ppp[91690]: Phase: deflink: dial -> carrier Aug 24 06:11:09 diesel ppp[91690]: Phase: Received NGM_PPPOE_ACNAME (hook "HN-XDSL") Aug 24 06:11:09 diesel ppp[91690]: Phase: Received NGM_PPPOE_SESSIONID Aug 24 06:11:09 diesel ppp[91690]: Phase: Received NGM_PPPOE_SUCCESS Aug 24 06:11:09 diesel ppp[91690]: Phase: deflink: carrier -> login Aug 24 06:11:09 diesel ppp[91690]: Phase: deflink: login -> lcp Aug 24 06:11:10 diesel ppp[91690]: Phase: bundle: Authenticate Aug 24 06:11:10 diesel ppp[91690]: Phase: deflink: his = CHAP 0x05, mine = none Aug 24 06:11:10 diesel ppp[91690]: Phase: Chap Input: CHALLENGE (17 bytes from BRUN-0176-03-11) Aug 24 06:11:10 diesel ppp[91690]: Phase: Chap Output: RESPONSE (04022758623) Aug 24 06:11:11 diesel ppp[91690]: Phase: Chap Input: SUCCESS Aug 24 06:11:11 diesel ppp[91690]: Phase: deflink: lcp -> open Aug 24 06:11:11 diesel ppp[91690]: Phase: bundle: Network Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sbin/ipfw ipfw2.c
Am 08.08.2006 um 07:40 schrieb Julian Elischer: Each dynamic entry has an extra linkage to allow it to be linked onto the appropriate slot. whenever you use an entry you take it out of where-ever it is and put it into it's new slot X seconds into the future. Wouldn't that be essentially a per-packet operation? You'd have to at least check whether the rule is still in the appropriate slot each time you reset the timer. Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: No DHCPOFFERS received.
Am 01.08.2006 um 04:43 schrieb Alexandre Martins Garcia: Hello everybody, I have a modem connected to my freebsd machine in ethernet, so to have a configuration from my ISP I did: hydrus[/home/amg]# dhclient fxp0 ... No DHCPOFFERS received. No working leases in persistent database - sleeping. Very clearly, there appears to be no DHCP server on the other end. If you have an *ADSL* modem (instead of the phone or ISDN variety), it is quite likely that your ISP requires you to use PPP over Ethernet (PPPoE). The handbook has a section explaining how to configure your system to connect via this method. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pppoe.html If you can show us your ISPs instructions for configuring a Windows or Mac system, I'm certain we can help convert those for FreeBSD. HTH, Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Name-based vhost with HTTPS (was Re: Can I pursuade someone to commit this patch?)
Am 01.08.2006 um 10:41 schrieb Josef Karthauser: I need to run a second SSL web server inside of a jail, however that needs another IP address because SSL is incompatible with HTTP/1.1. Depending on who you need to sign your certificate, you might be able to use multiple host names with a single IP and a single certificate: http://wiki.cacert.org/wiki/VhostTaskForce Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: using ipfw seems to interfere with socket communication
Am 28.06.2006 um 00:13 schrieb Mikhail Teterin: fconfigure $sock -blocking 0 lappend result c:[gets $sock] was always returning empty string, instead of the string "two", that was written into the socket and flushed. Is the test wrong, and such result is possible, or is dummynet triggering a bug? Unloading the dummynet module allows the test to succeed... The test is wrong. See recvfrom(2), which the gets will eventually invoke: If no messages are available at the socket, the receive call waits for a message to arrive, unless the socket is nonblocking (see fcntl (2)) in which case the value -1 is returned and the external variable errno set to EAGAIN. And Tcl gets(n): If end of file occurs while scanning for an end of line, the command returns whatever input is available up to the end of file. If chan- nelId is in nonblocking mode and there is not a full line of input available, the command returns an empty string and does not consume any input. If varName is specified and an empty string is returned in var- Name because of end-of-file or because of insufficient data in non- blocking mode, then the return count is -1. Note that if varName is not specified then the end-of-file and no-full-line-available cases can produce the same results as if there were an input line consisting only of the end-of-line character(s). Essentially, dummynet delays processing of that "two" line just long enough to break the code's assumption that TCP over the loopback interface is instantaneous. If my fading memory of TCP/IP Illustrated Vol 2 serves me right, that was actually the case at least back then: the sendto system call would push the data all the way down to lo0, which would immediately pass it back up until it ended up in the receiving socket buffer. Dummynet will queue the packet, regardless, so it won't get delivered until the next time dummynet processes queues. In non-blocking mode, you must always be prepared to wait for data. Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Traffic shaping part 2
Am 25.06.2006 um 07:55 schrieb Jax:
Anyone can give me a real life example, full ipfw traffic shaping
ruleset or something like that.
FWIW, here's the shaping section from my ipfw setup. I'm behind an
ADSL2 line, so I don't care about downstream bandwidth, but I do
about the upstream. This allows me to run BT at full rate and still
have decent ssh interactive and web browsing behaviour.
${fwcmd} pipe 1 config bw 480kbit/s
# up prio: TCP ACKs, SSH interactive, etc.
${fwcmd} queue 1 config pipe 1 weight 100 queue 20 mask all
# up std: everything else
${fwcmd} queue 2 config pipe 1 weight 50 queue 20 mask all
# up bt: bt etc.
${fwcmd} queue 3 config pipe 1 weight 1 queue 20 mask all
# favour small TCP packets (ACKs)
${fwcmd} add 200 queue 1 tcp from any to any iplen 1-100 xmit tun0
# ssh
${fwcmd} add 201 queue 1 tcp from any to any 22 iptos lowdelay xmit tun0
# DNS, NTP
${fwcmd} add 202 queue 1 udp from any to any 53, 123 xmit tun0
# BT etc.
${fwcmd} add 210 queue 3 tcp from 192.168.0.0/24 21530-21539 to any
xmit tun0
${fwcmd} add 211 queue 3 tcp from 192.168.0.0/24 6880-6889 to any
xmit tun0
${fwcmd} add 212 queue 3 tcp from 192.168.0.0/24 to any 6880-6889
xmit tun0
# default
${fwcmd} add 220 queue 2 tcp from any to any xmit tun0
--
Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: proposal: TCP rendevous
Am 27.11.2005 um 11:18 schrieb Paweł Małachowski: On Sat, Nov 26, 2005 at 10:18:49PM -0800, Julian Elischer wrote: I'm still thinking about connecting systems separated by NAT however. that's a trickier problem. you still need to use outgoing connections but no-one who is not in the path can not tell what the NAT'd packets looke like. BTW, I've heared Windows-behind-NAT-people ;) are using http:// hamachi.cc trick, however, I've never tried. 5/8 is reserved--for now. The software is binary-only. For a better alternative, check out OpenVPN. Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em(4) problems.
Am 05.05.2004 um 13:31 schrieb Søren Schmidt: Pawel Jakub Dawidek wrote: On Wed, May 05, 2004 at 12:42:48PM +0200, Pawel Jakub Dawidek wrote: +> Hi. +> +> I've problems with em(4) and IPSEC/FAST_IPSEC and TCP_STREAM netperf test. +> While running netperf tests between two FreeBSD machines directly connected +> em0 goes down once every few minutes and I've no idea why. +> Without IPSEC everything works just fine, with IPSEC/FAST_IPSEC it also +> works fine but for other tests (UDP_STREAM, TCP_RR, UDP_RR). For what its worth I have problems with one em based interface as well, it locks the machine solid when used: me too: FreeBSD 5.2-CURRENT #0: Tue Apr 13 18:50:30 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VERGISSNIX em0: port 0xc000-0xc01f mem 0xf200-0xf201 irq 12 at device 1.0 on pci2 em0: Bus reserved 0x2 bytes for rid 0x10 type 3 at 0xf200 em0: Bus reserved 0x20 bytes for rid 0x18 type 4 at 0xc000 em0: [GIANT-LOCKED] em0: Ethernet address: 00:e0:81:27:b6:12 em0: Speed:N/A Duplex:N/A em1: port 0xd300-0xd33f mem 0xf102-0xf103,0xf100-0xf101 irq 23 at device 2.0 on pci3 em1: Bus reserved 0x2 bytes for rid 0x10 type 3 at 0xf100 em1: Bus reserved 0x40 bytes for rid 0x18 type 4 at 0xd300 em1: [GIANT-LOCKED] em1: Ethernet address: 00:e0:81:27:b6:13 em1: Speed:N/A Duplex:N/A [EMAIL PROTECTED]:1:0: class=0x02 card=0x10198086 chip=0x10198086 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:2:0: class=0x02 card=0x10138086 chip=0x10138086 rev=0x00 hdr=0x00 # vmstat -ia irq12: em0 0 0 stray irq120 0 irq23: em1 3916723 3 stray irq230 0 em1 works; after bringing em0 up, machine locks solid after 2 to 5 minutes. -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange PPP negotiation problem with GPRS mobile phone
On Montag, 30. Juni 2003 23:36 Uhr +0200 Alessandro de Manzano <[EMAIL PROTECTED]> wrote: Now PPP seems to negotiate some IP address, but after about a second it still close the session... Could someone, please, help me understanding what's wrong now according to this log ? ;) Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: SendConfigAck(33) state = Ack-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: IPADDR[6] 192.168.100.101 Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression Jun 30 23:27:19 asusmobile ppp[275]: tun0: LCP: deflink: RecvTerminateReq(34) state = Opened Jun 30 23:27:19 asusmobile ppp[275]: tun0: LCP: deflink: LayerDown Jun 30 23:27:19 asusmobile ppp[275]: tun0: LCP: deflink: SendTerminateAck(34) state = Opened Jun 30 23:27:19 asusmobile ppp[275]: tun0: LCP: deflink: State change Opened --> Stopping Jun 30 23:27:19 asusmobile ppp[275]: tun0: CCP: deflink: State change Req-Sent --> Starting Jun 30 23:27:19 asusmobile ppp[275]: tun0: CCP: deflink: LayerFinish. The peer is disconnecting. This might be due to either the Van Jacobsen compression (option vjcomp), or the Link Quality Request Echo (option lqr) being active or inactive. IIRC, for a GPRS connection, the phone acts as the PPP peer, and at least my Nokia 6310i does not like LQR Echo and VJ. With both of them enabled, the connection keeps going for a few seconds, and then gets dropped by the peer. With both of them disabled, it works fine for me on T-Mobile netowrks in Germany, Austria and the US. HTH, Stefan -- Stefan Bethke, Phone +49 170 346 0140 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
