Re: Hello! re0 watchdog and high-ish traffic?
On 8/13/22 17:44, gm...@dnmx.org wrote: Hello there! Hello. Basically when I get the download speed in something like qBittorrent to 4Mbit/s, then my internet connection resets, and in `dmesg` I get "re0: watchdog timeout" then re0 goes DOWN and UP.. and sometimes it seems to also get stuck in that loop. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724 bye av.
Re: Any reason to not implement VRRP in FreeBSD?
On 1/26/23 17:08, Nicolas MASSE wrote: Is there currently any reason to not have an implementation of VRRP inside FreeBSD? https://www.freshports.org/net/freevrrpd (I remember I used it in the past, many many years ago; when CARP was introduced in base, I switched, so I don't know how good it works today). bye av.
bge performance inquiry
Hello. I'm evaluating a new box that will act as router... I've been offered BCM5720 network cards (which should run with the bge driver). Are they good WRT to stability and performance? I've always used Intel... Any good reason to stick with, e.g., an I210? bye & Thanks av.
Named warning
Hello. Lately, running bind 9.16.39, I'm seeing a lot of these (on several boxes): named[22122]: validating in-addr.arpa/SOA: got insecure response; parent indicates it should be secure I know the general answer (either a config problem upstream or a problem in my BIND validation), but in this case I don't think I have the problem. Or do I? Are others seeing these messages? bye & Thanks av.
OpenVPN suddenly working one way only
Hello. Not sure this is a question for FreeBSD or for OpenVPN directly... I'll try here first. I'm using OpenVPN quite heavily, as I have around 10 server-server tunnels, and several server-clients installations. They are all working properly except one, which will periodically start misbehaving. Both ends are FreeBSD 13.3, the protocol is UDP and I'm using tun interfaces. Simply put: handshake is gine, packets from host A to B get through, but packets from B to A do not. I can run tcpdump on both tun interfaces: _ if I ping A -> B, A sees packets going out, but none coming in, although B sees both; _ if I ping B -> A, B sees packets going out, but A sees nothing. Restarting openvpn on both ends does not help: handskake happens again, but the situation does not change. Looks more like a kernel/tun problem... Possibly rebooting (A or B?) would solve, but I can't do that easily. Also, I'm sure in some days (possibly weeks) it'll start working fine again by itself (!!!). Notice that both ends have other OpenVPN tunnels to different systems and they keep working while this one is not. Has anyone else seen something similar? Anything to try/check now that I'm getting the problem and I have no urge to solve? bye & Thanks av.
Re: OpenVPN suddenly working one way only
On 7/5/24 11:31, Ronald Klop wrote: Of course this can be a firewall or routing issue somewhere in between the hosts blocking traffic from B to A. Hmm... The two hosts can communicate with any other protocol. Also the VPN can handshake, so packets are exchanged correctly. I'm only using ipfw: no packet is logged as blocked, but, in any case, it blocks after tcpdumps sees them and I don't even see them. > Or both? Can you run tcpdump on the physical interfaces? What > traffic do you see on the openvpn port? Let's say, after handshake, I ping A -> B: _ A sees the request going out tun; _ A sees the UDP packet going out via physical interface; _ B sees the UDP packet arriving; _ B sees the request coming in via tun; _ B sees the answer going out via tun; _ B sees the UDP packet going out the physical interface; _ A doesn't see the UDP packet coming in (so obviously nothing on tun also). Can you switch to TCP? Would be a little work and using OpenVPN/TCP is highly discouraged. However, I just changed UDP port and it seems to work! I'm puzzled... So maybe some system in between my two hosts was blocking packets, but... after the handshake!?!?!? Very strange. Or host B has some trouble and changing its port helped??? In any case, thanks a lot for answering. bye av.
Re: OpenVPN suddenly working one way only
On 7/5/24 16:32, Rodney W. Grimes wrote: However, I just changed UDP port and it seems to work! The "solution" didn't last: after a little more than 3 hours, this tunnel stopped working again :( Strangely restarting openvpn on both sides fixed this, this time. Or host A has a zombie process with a UDP listen on the port? It's host B listening as a server: host A connects to it. So I guess I should look into host B... And no, "netstat -na" show no udp4 line with the choosen port, after I stop openvpn. To my ignorance, this reminds me of the "no buffer space available" I sometimes get with ping. That's just a wild guess, of course, but I suspect something is wrong with UDP on the "server" host... bye & Thanks av.
Re: OpenVPN suddenly working one way only
On 7/6/24 02:17, Rodney W. Grimes wrote: Host A *still* has/had a port open, and that port can lingere for several reasons, and that can cause issues. Ok, good, check both A and B. I had checked this too: neither A nor B had the port still open. MTU's? Have you manually checked path MTU to make sure that it can carry your payload correctly IN BOTH DIRECTIONS. I have seen asymetrical routes cause MTU issues due to it being smaller in one direction. That's the first thing I thought: however a simple ping does not get through and that's a small packed. bye & Thanks av.
Re: OpenVPN suddenly working one way only
On 7/6/24 17:02, Rodney W. Grimes wrote: Are you pinging the inside or outside address of the vpn? If you cant even ping the outside IP of a VPN you have basic connectivity problems that must be fixed before even attempting a VPN. I'll recap: I've got two hosts: A and B, which are in differnt sites, connected to the Internet with different ISPs. Pinging B's public IP from A's public IP, and vice versa, works, as does any other TCP based protocol (http, ssh, etc...); I have no UDP based protocol to test with; if it's needed I'll try and setup some. There's an UDP based OpenVPN tunnel originating from host A to host B: usually it works perfectly, but once in a few months it stops (and will usually start working again after some days/weeks). Other similar VPNs, which are present on both hosts, keep working. When the VPN does not work, packets do flow in one direction inside the tunnel from A to B. From B to A, they do seem to exit the tunnel from host B (according to tcpdump), but they never get to host A. It's not an MTU problem, as I tried ping, which uses very small packets. It's almost surely due to a problem with the UDP packets that implement the VPN: again, according to tcpdump they go out host B, but never reach host A. I tried stopping OpenVPN and starting it again: I got inconsistent results and need to investigate better; in any case it doesn't help. Moving the VPN to a different port on host B allowed it to start working again, but only for a few hours. After this time, the UDP packets from B to A were getting lost again. I can't reboot these hosts freely: it would help to check if any of them is the culprit or if it could be some router in the middle. I have no access to any router between A and B, but I'd be suprised they would drop such packets. Now the VPN is working, again I don't know why, so I can't conduct any more test. I'm sure it will happen again, maybe in a few months. bye & Thanks av.
Re: OpenVPN suddenly working one way only
On 7/6/24 18:13, Patrick M. Hausen wrote: Hello. It's almost surely due to a problem with the UDP packets that implement the VPN: again, according to tcpdump they go out host B, but never reach host A. Is it remotely possible that one of the ISPs blocks these UDP packets as part of an automatic "DoS protection" mechanism? Of course I cannot exclude it with 100% confidence. That said: _ host A has about 10 VPNs, only one is misbehaving, so I guess it's not ISP A; _ host B has an enterprise-grade contract, so they should not firewall anything; another one of the above VPNs connects to a different host which has the same type of contract with the same ISP and it works. Maybe it's the ISP or someone in between... I have no control over this. I'd like to exclude any local issue, about which I might actually do something. bye & Thanks av.
Re: OpenVPN suddenly working one way only
On 7/6/24 18:24, Michael Tuexen wrote: Or are any kind of NAT or Firewall involved which might loose state? Are you using public addresses on host A and B? Host B has a public IP address assigned to its "public" interface. Host A is behind NAT (it has a private IP assigned to its public interface). However, it has about 10 VPNs and only this one misbehaves (from time to time). The again, IIUC, NAT might lose state after some time... here I see the packet going out and nothing coming in immediately afterwards. bye & Thanks av. Guess I'll need to find a way to reboot the server, next time it happens. :(
if_bridge hangs server
Hello. I hope someone can help me with the following problem... The box runs a 8.3p7/i386 and has three physical ethernet interfaces: em0, em1 and fxp1. em0 and em1 are bonded into lagg0, over which carp0 and carp1 run. fxp0 has three vlans: vlan1, vlan2 and vlan3, over which there are respectively carp3/carp4, carp6/carp7, carp9/carp10. To make it clearer, here's the extract from my rc.conf: cloned_interfaces="lagg0 vlan1 vlan2 vlan3 carp0 carp1 carp3 carp4 carp6 carp7 carp9 carp10" ifconfig_em0="up" ifconfig_em1="up" ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 192.168.101.1 netmask 255.255.255.0" ifconfig_carp0="vhid 1 pass xxx 192.168.101.10" ifconfig_carp1="vhid 2 advskew 200 pass 192.168.101.10" ifconfig_fxp0="up" ifconfig_vlan1="inet xx.xxx.xx.xx netmask 255.255.255.248 vlan 4 vlandev fxp0" ifconfig_vlan2="inet xx.xxx.xxx.xxx netmask 255.255.255.248 vlan 2 vlandev fxp0" ifconfig_vlan3="inet 192.168.2.201 netmask 255.255.255.0 vlan 3 vlandev fxp0" ifconfig_carp3="vhid 4 pass xx.xxx.xx.xx" ifconfig_carp4="vhid 5 advskew 100 pass xx.xxx.xx.xx" ifconfig_carp6="vhid 7 pass xx xx.xxx.xxx.xxx" ifconfig_carp7="vhid 8 advskew 100 pass xxx xx.xxx.xxx.xxx" ifconfig_carp9="vhid 10 pass 192.168.2.203" ifconfig_carp10="vhid 11 advskew 100 pass 192.168.2.203" Now I need a tap based OpenVPN, so, per instructions I have found, I run: ifconfig bridge0 create addm lagg0 up After the above command is issued, the box won't live for other five minutes; everythings works fine as before, but the server will soon hang: no crashdump, no message, no reboot, just a sudden freeze. The only way to restart is the reset button. So I'm stuck and don't know what to do. Are there any known issue regarding if_bridge which I might be encountering? Anything related to if_bridge interaction with carp, vlan or lagg? With ipfw? Any hint on how to debug this? Would an upgrade to 9.1 help? bye & Thanks av. ___ 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"
Network troubles after 8.3 -> 8.4 upgrade
Hello. Three days ago I upgraded an amd64 8.3 box to the latest 8.4. Since then the outside network is misbehaving: large mails are not sended (although small ones do), svn operations will work for a while, then come to a sudden stop, etc... Perhaps the most evident test is "wget"ting a big file: it will download some chunk, halt; restart after a while and download another chunk; lose the connection once again, then restart and so on. I remember a couple of similar experiences in the past, from which I got out by disabling TSO; however those box had fxp cards, while this has an em. In any case disabling TSO did not help. This is the relevant part of rc.conf: cloned_interfaces="lagg0 vlan1 vlan2 vlan3 carp0 carp1 carp3 carp4 carp6 carp7 carp9 carp10" ifconfig_igb0="up" ifconfig_igb1="up" ifconfig_lagg0="laggproto lacp laggport igb0 laggport igb1 192.168.101.4 netmask 255.255.255.0" ifconfig_lagg0_alias0="inet 192.168.101.101 netmask 0x" ifconfig_carp0="vhid 1 advskew 100 pass xxx 192.168.101.10" ifconfig_carp1="vhid 2 pass 192.168.101.10" ifconfig_em0="up" ifconfig_vlan1="inet 81.174.30.11 netmask 255.255.255.248 vlan 4 vlandev em0" ifconfig_vlan2="inet 83.211.188.186 netmask 255.255.255.248 vlan 2 vlandev em0" ifconfig_vlan3="inet 192.168.2.202 netmask 255.255.255.0 vlan 3 vlandev em0" ifconfig_carp3="vhid 4 advskew 100 pass 81.174.30.12" ifconfig_carp4="vhid 5 pass xxx 81.174.30.12" ifconfig_carp6="vhid 7 advskew 100 pass xx 83.211.188.187" ifconfig_carp7="vhid 8 pass xxx 83.211.188.187" ifconfig_carp9="vhid 10 advskew 100 pass 192.168.2.203" ifconfig_carp10="vhid 11 pass 192.168.2.203" ifconfig_lo0_alias0="inet 127.0.0.2 netmask 0x" ifconfig_lo0_alias1="inet 127.0.0.3 netmask 0x" ifconfig_lo0_alias2="inet 127.0.0.4 netmask 0x" As you can see the setup is quite complicated, but worked like a charm until the upgrade; actually the internal net (igb+lagg+carp) still does, so this is what points me toward em0, where I cannot seem to get any kind of stability. The card is em0@pci0:6:0:0: class=0x02 card=0x10828086 chip=0x107d8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet I tried disabling TSO, RXCSUM, TXCSUM, VLANHWTAG, VLANHWCSUM, VLANHWTSO... I tried putting the card into 10baseT/UTP mode... I tried sysctl net.inet.tcp.tso=0... None helped. Maybe I'm barking up the wrong tree, but nothing is in the logs to help... Nor did Google or wading through bug reports. Now I could restore the dumps I made before upgrading to 8.4 (but I'd really like to avoid this), try to upgrade even further to 9.2 (although this will be a lot of work and I'm not looking forward to it as a shot in the dark), drop in another NIC... What I'd really like, however, is some insight. Is this a known problem of some sort? Is this card or this driver known to be broken? Is there any way I could get some debugging info? Any hint is appreciated (and I need it badly :( !!!). bye & Thanks av. ___ 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: Network troubles after 8.3 -> 8.4 upgrade
On 04/17/14 23:45, John Nielsen wrote: Thanks for answering John. My first thought was TSO as well, since I've seen the symptoms you describe a few times on systems running 10.0. > Do you use IPFW or any kind of NAT on this system? Yes, I use ipfw to firewall, to divert packets to natd and also to forward specific traffic to three different gateways. I think I added a "10 allow ip from any to any" rule for a brief period of time to exclude ipfw's interference, but I'm not sure and eventually I'll try again next week. When an application encounters a network problem, does it report or log anything at all? Simply a timeout. Anything in the kernel log/dmesg? I wished so; unfortunately, as I wrote, unless there's some sysctl to tweak I get no suck info. Otherwise my only other thought would be the driver. > Can you try reverting only the em(4) driver back to 8.3? Worth a try I guess! > Build modules and a kernel without em(4) from unmodified 8.4 src, load em(4) as a module, > confirm that the problem persists. Ok, easy. Replace the contents of src/sys/dev/e1000, src/sys/modules/em and > src/sys/conf/files with those from an 8.3 src tree (or otherwise > revert revision 247430), rebuild em module, unload/reload or reboot, > see if problem goes away. (Could be somewhat complicated by the fact > that you also have igb interfaces which also use code from the e1000 > directory, but rather than speculate I'll leave solving that as an > exercise for someone else.) Hmmm, sounds a bit complicated... would simply dropping if_em.ko in from a 8.3 box work? bye & Thanks av. ___ 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: Network troubles after 8.3 -> 8.4 upgrade
On 04/19/14 19:19, Andrea Venturoli wrote: Hmmm, sounds a bit complicated... would simply dropping if_em.ko in from a 8.3 box work? Ok, I'll answer myself. I'm now running 8.3's if_em.ko (binary from another system), on an 8.4 kernel. The behaviour is the same as before. However, further researches show em is not the culprit. Rather, ipfw is: in fact dynamic rules are created, but will always timeout after 20 s (no matter if idle or not). Someway the outgoing packet triggers the dynamic rule, but it doesn't seem to get past the SYN phase. The ruleset here is quite a mess, so I need to investigate it better. What suprise me is that it worked differently with 8.3! Well, at least now I know where to look... Thanks to anyone who replied. bye av. ___ 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"
Server with multiple public IP
Hello. This has probably come up several times, however... I've got a server which has two (or more) interfaces with public IPs. Let's say, as an example (with fictional IPs): ifconfig_vlan1="inet 1.0.0.2 netmask 255.255.255.248..." ifconfig_vlan2="inet 2.0.0.2 netmask 255.255.255.248..." Of course, I can only have a default route, let's say 1.0.0.1. This is fine for outgoing traffic and for incoming connections on vlan1. However, when someone from the outside connects to 2.0.0.2, reply packets still go out through 1.0.0.1 (on vlan1), but they should go through vlan2 to 2.0.0.1 The only way I found so far to achieve this, is through ipfw: ipfw add 30 fwd 2.0.0.1 tcp from 2.0.0.2 to not 2.0.0.0/29 out This more or less works, but it will break ipfw firewalling (since after that rule matches, "the search terminates"). Besides, I don't feel this is a very clean solution. So I wonder: do other ways exist to achieve this? Any best practice? I thought natd might help, but found no reference to this functionality in its docs... Does any other program exists which I can "divert" packets to, which would modify and reinject them as natd does? Another thing I though of would be combining two firewalls (ipfw + pf/ipf), letting one do the filtering and leaving the above problem to the other. I'm not sure how hard this would be, however, so if a simple solution exists... Any hint appreciated. bye & Thanks av. ___ 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: Server with multiple public IP
On 04/28/14 11:18, Andreas Nilsson wrote: You could put all the services which are on 2.0.0.2 in a separate fib and there have another default-route. Thanks, but unfortunately I can't, since some services must be able to answer on both addresses. Maybe I could use socket in one fib to proxy to the other, but that would probably make a mess in the logs when I have to identify who connects to what and from where. bye & Thanks av. ___ 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: Server with multiple public IP
On 04/28/14 11:16, Dominic Froud wrote: You want source-based routing. Thanks, that term will help me in my searches. I have this situation and I used pf(4) to do it with a rule like: pass out quick route-to ( vlan2 ) from 2.0.0.0/29 to any no state As a variation you can give an optional next-hop address if you have a static router for that vlan, e.g. if your router is 2.0.0.1: pass out quick route-to ( vlan2 2.0.0.1 ) from 2.0.0.0/29 to any no state Also, you can run pf and ipfw at the same time! Thanks a lot, I think I'll try this. bye av. ___ 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: Server with multiple public IP
On 04/28/14 11:16, Dominic Froud wrote: On 28/04/2014 09:58, Andrea Venturoli wrote: I've got a server which has two (or more) interfaces with public IPs. Let's say, as an example (with fictional IPs): ifconfig_vlan1="inet 1.0.0.2 netmask 255.255.255.248..." ifconfig_vlan2="inet 2.0.0.2 netmask 255.255.255.248..." Of course, I can only have a default route, let's say 1.0.0.1. This is fine for outgoing traffic and for incoming connections on vlan1. However, when someone from the outside connects to 2.0.0.2, reply packets still go out through 1.0.0.1 (on vlan1), but they should go through vlan2 to 2.0.0.1 You want source-based routing. I have this situation and I used pf(4) to do it with a rule like: pass out quick route-to ( vlan2 ) from 2.0.0.0/29 to any no state As a variation you can give an optional next-hop address if you have a static router for that vlan, e.g. if your router is 2.0.0.1: pass out quick route-to ( vlan2 2.0.0.1 ) from 2.0.0.0/29 to any no state Also, you can run pf and ipfw at the same time! Hope this helps, I ended up using this solution... so far so good (and so easy). Thanks a lot. bye av. ___ 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"
MTU not regrowing?
Hello. Today I experienced something weird (at least for me) on a 8.4 system: _ the system had vlan3 interface, with default MTU (1500 bytes); _ "ping -D -s 1400 somehost" would work, but "ping -D -s 1500 somehost" would yield "frag needed and DF set" (forgive me if the message is not exact, I don't have it anymore); _ to make some tests I reduced MTU size with "ifconfig vlan3 mtu 500"; _ now, of course, "ping -D -s 400 somehost" would work, but "ping -D -s 500 somehost" would yield "frag needed and DF set"; _ then I raised MTU again with "ifconfig vlan3 mtu 1500" (notice ifconfig would actually report this as "mtu 1500" was shown); _ however the results were as before, i.e. "ping -D -s 400 somehost" would work, but "ping -D -s 500 somehost" would yield "frag needed and DF set"; _ no way I could ping with a packet bigger than 500 bytes until I rebooted. Is this expected behaviour? Any way to get around this? bye & Thanks av. ___ 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: MTU not regrowing?
On 06/24/14 21:03, John Hay wrote: Do a "route get somehost" and see what mtu is returned. You might be able to delete or tweak that route. Thanks a lot! I learned something new :) I'll try this next time I have the chance. bye av. ___ 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: MTU not regrowing?
On 06/25/14 02:01, Charles Swiger wrote: Does "ifconfig vlan3 down; ifconfig vlan3 up" do any good? Or that run against the physical NIC? Can't try this now, I'll do when I can play again with this box. What is the ethernet HW em0@pci0:6:0:0: class=0x02 card=0x10828086 chip=0x107d8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet > and are you using VLAN_HWTAGGING capability? Yes. bye & Thanks av. ___ 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: MTU not regrowing?
On 06/25/14 15:23, Andrea Venturoli wrote: On 06/25/14 02:01, Charles Swiger wrote: Does "ifconfig vlan3 down; ifconfig vlan3 up" do any good? Or that run against the physical NIC? None of the two. John was right about the route. bye & Thanks av. ___ 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: MTU not regrowing?
On 06/24/14 21:03, John Hay wrote: Do a "route get somehost" and see what mtu is returned. You are right, I see a route with the old, lesser MTU. You might be able to delete or tweak that route. How do I do this? I tried "route delete", but it doesn't help. bye & Thanks av. ___ 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: MTU not regrowing?
On 07/02/14 04:53, John-Mark Gurney wrote: How do I do this? I tried "route delete", but it doesn't help. route change -mtu XXX This does not work: the route is deemed as non-existent. bye & thanks av. P.S. I'm writing this more out of curiosity, than of real need; no need to solve this, really. ___ 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_xl on 8.2
Hello. Just to say today I upgraded from 8.1 to 8.2 and xl0 stopped working. It is detected: xl0: <3Com 3c900B-COMBO Etherlink XL> port 0xd800-0xd87f mem 0xfdefe000-0xfdefe07f irq 17 at device 7.0 on pci1 xl0: selecting 10baseT transceiver, half duplex xl0: Ethernet address: 00:50:04:22:a9:c0 xl0: [ITHREAD] I can "ifconfigure" it, but no packet will get in or out. This is not a problem for me, since I had another card available. However, if anyone is interested, I'm available for details or testing. bye av. ___ 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: if_xl on 8.2
On 11/23/11 19:05, Brian Seklecki (Mobile) wrote: Send us: grep ifconfig /etc/rc.conf ifconfig -a ifconfig -m netstat -i netstat -rn netstat -i arp -an ___ 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: if_xl on 8.2
On 11/23/11 19:05, Brian Seklecki (Mobile) wrote: Send us: grep ifconfig /etc/rc.conf ifconfig -a ifconfig -m netstat -i netstat -rn netstat -i arp -an For both the working and non-working cards to compare. Sorry for the noise... I accidentally removed the "media" option from rc.conf and the card is not able to decide between UTP and BNC by itself. bye & Thanks av. ___ 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"
Intel 82550 Pro/100 Ethernet and TSO troubles
Hello. I recently installed 8.2 with the following card: > dmesg > ... fxp0: port 0xdc00-0xdc3f mem 0xfebfb000-0xfebfbfff,0xfebc-0xfebd irq 20 at device 5.0 on pci4 > ... > pciconv -lv > ... fxp0@pci0:4:5:0:class=0x02 card=0x00408086 chip=0x12298086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet > ... I had weird problems, especially due to ICMP/fragmentation/MTU/... issues. After hours spent in debugging, I noticed tcpdump showing ICMP packets with wrong checksums and that TSO4 was enabled. "ifconfig fxp0 -tso" seemed to solve everything. Don't know if it's a bug in the card, in the driver or what... Maybe it shouldn't be enabled by default? I also have fxp1: > dmesg > ... fxp1: port 0xd880-0xd8bf mem 0xfebfa 000-0xfebfafff,0xfea0-0xfeaf irq 21 at device 6.0 on pci4 ... pciconv -lv ... fxp1@pci0:4:6:0:class=0x02 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet > ... TSO was not enabled on this by default. Feel free to ask, in case you need any further info. bye av. ___ 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: Intel 82550 Pro/100 Ethernet and TSO troubles
On 12/14/11 20:59, YongHyeon PYUN wrote: AFAIK the firmware of controller has no known TSO issue so it indicates a bug in driver. What makes me wonder is ICMP ECHO packet should not be affected by TSO and I have no clue at this moment. I wasn't talking about ICMP ECHO. What happened was: a) the client connected to my server, advertising a TCP MSS of X; b) my server started sending with packets larger than X (possibly it misinterpreted MSS size???); c) an ICMP packet arrived, asking my server to send packets no larger than Y (I guess it was ignored); d) my server kept resending the same (too big) packets; e) it eventually reduced packet size, but it was still larger than Y; ... Wireshark showed some wrong checksums (I believe on the ICMP packet, but I might remember wrong). Of course this made a bell ring and removing TSO solved everything. (Here, I assume you've captured packets on receiver side since bpf sees packets before hardware computes checksum.) Yes, although I don't have them anymore. If you have a reliable way that reproduces the issue, let me know. I can turn TSO on again, save the packets and send them to you. I just hope nothing changes on the Internet in between the server and the client. Let me know if you need/want this and I'll arrange in the next few days. bye & Thanks av. ___ 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: Intel 82550 Pro/100 Ethernet and TSO troubles
On 12/14/11 22:32, YongHyeon PYUN wrote: Wireshark showed some wrong checksums (I believe on the ICMP packet, but I might remember wrong). You can check whether you received bad checksummed frames with netstat(1). I tried "netstat -ind", but it shows no Ierrs/Idrop/Oerrs/Odrop. Is simple downloading from client to server is enough to trigger the issue? Yes and no. Depending on where the client is located (on the Internet) and/or the protocol used, I get either failures or ridicuolous performance (i.e. 58-60kB/s without TSO vs. 1-2kB/s with TSO). Packet capture that shows the problem would be great to know what's going on here. I'll send them to you privately. You'll see tso.dump and notso.dump: they are both from the same client downloading the same (random) file (the file name was changed only to prevent possible caching). See notso.dump is perfect, while tso.dump shows a lot of potential problems. Would you try attached patch and let me know it goes? Sorry, it seems extra pull up for TCP payload may not be required here. Try this instead. I see a little increase in performance (2-3kB/s instead of 1-2kB/s); this might however well depend on external factors. Still it is very different from what I'm get without TSO. bye & Thanks av. P.S. I can live well without TSO; I'm just doing this to let the software improve. Go ahead only if *you* are interested. ___ 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: Intel 82550 Pro/100 Ethernet and TSO troubles
On 12/15/11 23:13, YongHyeon PYUN wrote: I tried "netstat -ind", but it shows no Ierrs/Idrop/Oerrs/Odrop. Use -s option which will show statistics for each network protocols. Search 'discarded for bad checksums' from the output. Still all bad counters at zero. You'll see tso.dump and notso.dump: they are both from the same client downloading the same (random) file (the file name was changed only to prevent possible caching). See notso.dump is perfect, while tso.dump shows a lot of potential problems. Thanks. Thanks go to you! :-) Thanks for testing. Based on dump file, I tried various MTU configuration and I was not able to reproduce it. By chance, are you using firewall(pf/ipfw/ipf) or bridge(4)? If I remember correctly some firewall rules are not compatible with TSO. For bridge, if one member of bridge does not support TSO, TSO should be disabled. Very interesting: I'm not using bridge on this host, but I'm using ipfw! Which rules are incompatible? Any pointer on this? I'm also using CARP, in case it could matter, but not on this interface. bye & Thanks av. ___ 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: Intel 82550 Pro/100 Ethernet and TSO troubles
On 12/16/11, Eugene Grosbein wrote: (Sorry Eugene, I didn't get your message until I searched the web). > Do you use NAT? man ipfw clearly states: > > ipfw nat is not compatible with > the TCP segmentation offloading (TSO). Thus, to reliably nat your net- > work traffic, please disable TSO on your NICs using ifconfig(8) Yes, I'm using ipfw and NAT, so this is the problem. Thanks for solving me this. I'm just wondering if it was a good idea to enable TSO by default without at least a warning in the release notes or in UPDATING. This has caused me some headaches, which is ok, I'm just sorry I've also wasted some of YongHyeon's time; what's worse, I believe I won't be the only one hit by this. bye & Thanks av. ___ 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"
LAGG and CARP troubles
Hello. I'm using 7.4p6/i386 and this is (a part of) my configuration cloned_interfaces="lagg0 vlan1 vlan2 vlan3 carp0 carp1 carp6 carp7 carp9 carp10" ifconfig_em0="up" ifconfig_em1="up" ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 192.168.101.1 netmask 255.255.255.0" ifconfig_carp0="vhid 1 pass xxx 192.168.101.10" ifconfig_carp1="vhid 2 advskew 200 pass 192.168.101.10" lagg0 would work fine (using two cables, recovering from one disconnection, etc...). However carp0 will stay MASTER only with one cable; as soon as I connect both em interfaces, I'll get: kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) What am I doing wrong? bye & Thanks av. ___ 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"
CARP and LACP
Hello. Fast question: are the two above compatible? Can I use CARP over a lagg interface? bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
FreeBSD + Samba + Active Directory
Hello. I have a setup with two FreeBSD 6.3 domain controllers using samba + openldap + nss_ldap. The company might be switching to Active Directory soon (not my choice, before you ask :-), so I might need to reconfigure the two FreeBSD boxes to become AD members (with winbindd, nss, whatever). I see there's a lot of documentation around and I'm going to read that; here I just want to ask if everything works as advertised, if there are some differences between theory and practice, bugs to watch for, gotchas, etc... Thanks in advance to anyone who cares to share it's experience. bye & Thanks av. ___ 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"
Wi-Fi bridge interferes with CARP
Hello. I'm curios about something which happened during a test in one of my networks. Two FreeBSD 6.3 boxes (one i386, one amd64) share some IP through CARP. Now, as soon as I plugged a wi-fi bridging access point on the net (which took it's IP from DHCP only for management), I started to see this in the i386 box's logs: Oct 22 09:49:04 x kernel: arp_rtrequest: bad gateway 192.168.101.10 (!AF_LINK) Oct 22 09:49:04 x kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) Oct 22 09:49:07 x kernel: arp_rtrequest: bad gateway 192.168.101.10 (!AF_LINK) Oct 22 09:49:07 x kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) ... and so on every 3 seconds. The above IP is the one the two machines are sharing on the local network. Nothing like that appeared on the amd64 box. Only one Windows machine was (sometimes) using the access point. Did anyone experience such a thing? Any clue? bye & Thanks av. ___ 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"
snort on multiple interfaces
Some years ago, I checked to see whether I would be able to let a single snort process listen on more than one NIC. At the time it was only possible in Linux. Now, I searched a bit, but nothing new came up. Did anything improve since then? Do we still need multiple snort processes to listen on more than one interface? Can some netgraph node help with this? bye & Thanks av. ___ 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"
ipfw uid and mpsafenet
Hello. I've got a 6.3 box in which I needed to use debug.mpsafenet=0 in order to avoid deadlocks with ipfw uid rules. I'm thinking of upgrading this to 7.2 and I see the above variable has gone away. Does this mean it is now safe to use such ipfw rules? The last things I could find wrt this matter is this thread: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/arch/2007-07/msg00108.html, but it's from 2007... Any other caveat? bye & Thanks av. ___ 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"
Connecting to a WatchGuard box
Hello. A customer of mine was connecting to a remote WatchGuard box through their Mobile VPN client. Now I'd like the server to take over that and le the whole network connect. Did anyone ever succeded in this? Is it possible? Should be IPSEC, but anyone has an how-to? bye & Thanks av. ___ 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"
CARP + LAGG problem
Hello. I've a couple of 7.2p7 servers (one i386, the other amd64) which are working in parallel using CARP. Recently I bonded two interfaces on the former and CARP stopped working. Here's the relevant part from rc.conf on the first box: ifconfig_em0="up" ifconfig_em1="up" ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 192.168.101.1 netmask 255.255.255.0" ifconfig_fxp0="inet 192.168.0.3 netmask 255.255.255.0" ifconfig_fxp0_alias0="inet 192.168.2.3 netmask 255.255.255.0" cloned_interfaces="lagg0 carp0 carp1 carp2 carp3 carp4 carp5" ifconfig_carp0="vhid 1 pass AAA 192.168.101.10" ifconfig_carp1="vhid 2 advskew 100 pass 192.168.101.10" ifconfig_carp2="vhid 3 pass 192.168.0.4" ifconfig_carp3="vhid 4 advskew 100 pass 192.168.0.4" ifconfig_carp4="vhid 5 pass EE 192.168.2.4" ifconfig_carp5="vhid 6 advskew 100 pass FFF 192.168.2.4" And on the second one: ifconfig_em0="inet 192.168.101.4 netmask 255.255.255.0" ifconfig_xl0="inet 192.168.2.2 netmask 255.255.255.0" ifconfig_xl0_alias0="inet 192.168.0.2 netmask 255.255.255.0" cloned_interfaces="carp0 carp1 carp2 carp3 carp4 carp5" ifconfig_carp0="vhid 1 advskew 100 pass AAA 192.168.101.10" ifconfig_carp1="vhid 2 pass 192.168.101.10" ifconfig_carp2="vhid 3 advskew 100 pass 192.168.0.4" ifconfig_carp3="vhid 4 pass 192.168.0.4" ifconfig_carp4="vhid 5 advskew 100 pass EE 192.168.2.4" ifconfig_carp5="vhid 6 pass FFF 192.168.2.4" I also have in both boxes' sysctl.conf: net.inet.carp.arpbalance=1 net.inet.carp.preempt=1 net.inet.carp.log=2 As I said, everything worked fine as long as I was simply using em0 on the first box; since I switched it to lagg, carp0 will stay in BACKUP mode on both box, so some internal IPs won't get any answer. In the logs (of the first box) I'll get tons of the following messages: kernel: arp_rtrequest: bad gateway 192.168.101.10 (!AF_LINK) kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) The only way I found to let everyone get the service they excpect is to issue "ifconfig carp0 down" on the faulty box, so that the other will be master for everyone. Strangely, all the other carp interfaces don't seem to be affected. Any help? bye & Thanks av. P.S. Should not be a firewall problem, since i tried allowing all traffic and it didn't help. ___ 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"
Warnings with TSO on em
Hello. For quite a while, I've been seeing in the logs a lot of messages like the following: snort: (snort_decoder) WARNING: IP dgm len < IP Hdr len! I'm not sure about this, but I suspect they started when I upgraded from 6.3 to 7.2. Today, while investigating another problem, I decided I had to move this out of the way; tcpdump showed zero-length IP packets and Google told me they might be the result of TSO on the em cards. So I checked and, yes, I had TSO enabled (by default). "ifconfig em0 -tso" made this noise go away. Now I'm looking for some more insight: if it's only a performance problem, I don't think I'll be hit, but could there be other side effects? # uname -a FreeBSD x..xx 7.2-RELEASE-p7 FreeBSD 7.2-RELEASE-p7 #9: ... # pciconf -l|grep em e...@pci0:6:0:0: class=0x02 card=0x34768086 chip=0x10968086 rev=0x01 hdr=0x00 e...@pci0:6:0:1: class=0x02 card=0x34768086 chip=0x10968086 rev=0x01 hdr=0x00 I found some thread suggesting this might possibly be a bug with the em driver, but there was no follow up for more than a year. bye & Thanks av. P.S. I had another problem on this machine: when I bonded the the two "em" interfaces into a "lagg" one, carp stopped working properly. Now I wonder if the two issues might be related... ___ 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"
Atheros ale problems
Hello. I'm having problems with 8.0/amd64 with the following card: a...@pci0:1:0:0:class=0x02 card=0x83041043 chip=0x10261969 rev=0xb0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' class = network subclass = ethernet This is connected to a 100Mb/s Full Duplex switch with no fancy features. Sometimes, while connected through ssh to this box, I get kicked out with: Disconnecting: Corrupted MAC on input. or: Disconnecting: Bad packet length 1686869659. At the same time on the server's log and console, I see: kernel: ale0: watchdog timeout -- resetting kernel: ale0: could not disable Tx/Rx MAC(0x0008)! kernel: ale0: link state changed to DOWN kernel: ale0: link state changed to UP I'm setting up this box, so I can't speak of other protocols/applications yet. I saw some threads about this dating back to 2008 and related to EEEPCs, but this was supposed to be fixed. Any help? bye & Thanks av. ___ 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: Atheros ale problems
Il 07/02/10 00:41, Pyun YongHyeon ha scritto: Hello. I'm having problems with 8.0/amd64 with the following card: a...@pci0:1:0:0:class=0x02 card=0x83041043 chip=0x10261969 rev=0xb0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' class = network subclass = ethernet This is connected to a 100Mb/s Full Duplex switch with no fancy features. Sometimes, while connected through ssh to this box, I get kicked out with: Disconnecting: Corrupted MAC on input. or: Disconnecting: Bad packet length 1686869659. At the same time on the server's log and console, I see: kernel: ale0: watchdog timeout -- resetting kernel: ale0: could not disable Tx/Rx MAC(0x0008)! kernel: ale0: link state changed to DOWN kernel: ale0: link state changed to UP I'm setting up this box, so I can't speak of other protocols/applications yet. I saw some threads about this dating back to 2008 and related to EEEPCs, but this was supposed to be fixed. Any help? Show me the output of "ifconfig ale0" and "sysctl dev.ale.0.stats". And see whether your switch also agrees on resolved speed/duplex of established link. Sorry for taking so long: the machine had been shut down nad was moved in production and powered back up only yesterday. So far I didn't see that problem again, but I don't think it is sustaining as much traffic as when I was installing everything. Also the switch it was connected to at the time was a 100Mb/s one; the one it's connected to now is 1000Mb/s. In both case it is/was a dumb switch and I had no physical access, so I could not check the lights. So I doubt the data you asked for can help, however: # ifconfig ale0 ale0: flags=8843 metric 0 mtu 1500 options=319a ether 00:26:18:d6:6a:e5 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active # sysctl dev.ale.0.stats dev.ale.0.stats.rx.good_frames: 213391 dev.ale.0.stats.rx.good_bcast_frames: 159179 dev.ale.0.stats.rx.good_mcast_frames: 140 dev.ale.0.stats.rx.pause_frames: 1288 dev.ale.0.stats.rx.control_frames: 0 dev.ale.0.stats.rx.crc_errs: 0 dev.ale.0.stats.rx.len_errs: 0 dev.ale.0.stats.rx.good_octets: 18379370 dev.ale.0.stats.rx.good_bcast_octets: 13706715 dev.ale.0.stats.rx.good_mcast_octets: 13375 dev.ale.0.stats.rx.runts: 0 dev.ale.0.stats.rx.fragments: 0 dev.ale.0.stats.rx.frames_64: 264057 dev.ale.0.stats.rx.frames_65_127: 15812 dev.ale.0.stats.rx.frames_128_255: 43486 dev.ale.0.stats.rx.frames_256_511: 11514 dev.ale.0.stats.rx.frames_512_1023: 129 dev.ale.0.stats.rx.frames_1024_1518: 167 dev.ale.0.stats.rx.frames_1519_max: 0 dev.ale.0.stats.rx.trunc_errs: 0 dev.ale.0.stats.rx.fifo_oflows: 0 dev.ale.0.stats.rx.rrs_errs: 0 dev.ale.0.stats.rx.align_errs: 0 dev.ale.0.stats.rx.filtered: 120486 dev.ale.0.stats.tx.good_frames: 71638 dev.ale.0.stats.tx.good_bcast_frames: 2 dev.ale.0.stats.tx.good_mcast_frames: 0 dev.ale.0.stats.tx.pause_frames: 0 dev.ale.0.stats.tx.control_frames: 0 dev.ale.0.stats.tx.excess_defers: 0 dev.ale.0.stats.tx.defers: 0 dev.ale.0.stats.tx.good_octets: 66527894 dev.ale.0.stats.tx.good_bcast_octets: 0 dev.ale.0.stats.tx.good_mcast_octets: 0 dev.ale.0.stats.tx.frames_64: 3611 dev.ale.0.stats.tx.frames_65_127: 14373 dev.ale.0.stats.tx.frames_128_255: 3796 dev.ale.0.stats.tx.frames_256_511: 2106 dev.ale.0.stats.tx.frames_512_1023: 3108 dev.ale.0.stats.tx.frames_1024_1518: 44644 dev.ale.0.stats.tx.frames_1519_max: 0 dev.ale.0.stats.tx.single_colls: 0 dev.ale.0.stats.tx.multi_colls: 0 dev.ale.0.stats.tx.late_colls: 0 dev.ale.0.stats.tx.excess_colls: 0 dev.ale.0.stats.tx.abort: 0 dev.ale.0.stats.tx.underruns: 0 dev.ale.0.stats.tx.desc_underruns: 0 dev.ale.0.stats.tx.len_errs: 0 dev.ale.0.stats.tx.trunc_errs: 120 bye & Thanks av. ___ 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"
CARP over LAGG
Hello. On a couple of 7.2 systems, I've got some carp interfaces build upon a physical interface (em0 or igb0) and everything works fine. On both box I've tried aggregating two interfaces (resp. em0+em1 and igb0+igb1) into a lagg0 interface, using LACP. However, in this case CARP will stop working as all carp devices which work over lagg0 will stay in INIT state. Is this a bug? Is "carp over lagg" possible at all? bye & Thanks av. ___ 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"
pf stuck
Hello. Today a box of mine (8.4p16/amd64) stopped working as a router; I don't have a clear picture, but the internal nets were working perfectly, while the external interfaces lagged, dropped connections or stopped packets from passing. The box is running pf (for handling multiple Internet lines) + ipfw (for firewalling). I tried a simple telnet xxx:80 and this is what I observed: _ tcpdump would see packets going out and replies coming in; _ an early ipfw allow rule with setup keep-state would see no packet going out and would not create any dinamic rule. This lead me to look into pf... "/etc/rc.d/pf restart" did not solve. "/etc/rc.d/pf stop ; /etc/rc.d/pf start" did! These are my pf rules: pass out quick inet from 192.168.x.0/24 to 192.168.y.0/24 no state pass out quick inet from 192.168.x.0/24 to 192.168.z.0/24 no state pass out log quick route-to (vlan3 192.168.x.x) inet from 192.168.x.0/24 to ! 192.168.x.0/24 no state pass out quick inet from a.b.c.d/29 to 192.168.y.0/24 no state pass out quick inet from a.b.c.d/29 to 192.168.z.0/24 no state pass out log quick route-to (vlan1 a.b.c.e) inet from a.b.c.d/29 to ! a.b.c.d/29 no state pass out quick inet from i.j.k.l/29 to 192.168.z.0/24 no state pass out quick inet from i.j.k.l/29 to 192.168.z.0/24 no state pass out log quick route-to (vlan2 i.j.k.m) inet from i.j.k.l/29 to ! i.j.k.l/29 no state These rules are working fine, but have hanged already twice in two weeks (once on this box, once on an almost identical one). Is there any known problem wrt running pf? pf+ipfw? pf on 8.4? Any hint on how to search for what's wrong? bye & Thanks av. P.S. Please, forgive me, but I'm quite noob with pf. ___ 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: pf stuck
On 09/29/14 20:21, Ermal Luçi wrote: Probably is better you ask this on freebsd-pf@. Thanks, I see you have already cc:ed it. Though this sounds like state limit reached. Can this happen even if all my pf rules have "no state"? bye & Thanks av. ___ 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"
Dynamic ipfw rules' top
Hello. This might be a strange idea, but does such a thing exist? I mean: is there any tool that can show in real-time which dynamic rules are active, their timers, etc... like top does for processes? bye & Thanks av. ___ 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"
ipfw dyn_keepalive
Hello. I'm having some troubles with dynamic rules and keep-alives... Let's say a client connect to a TCP port on my server and a keep-state rules allows the connection; the connection is setup correctly and some data exchanged. Then there is some minutes of silence and the rule expires. However, I read in "man ipfw" that if net.inet.ip.fw.dyn_keepalive=1 (which is holds by default and I verified in my case): "A keepalive is generated to both sides of the connection every 5 seconds for the last 20 seconds of the lifetime of the rule". If I understand that correctly, then these rules should never expire (as long as the client answers those packets, I suppose); this is however in contrast to what I experience. I looked around, but found no pointers about this. How is it supposed to work? Does it need anything special on the client side or is it expected to always answer those packets? Any good document about this? bye & Thanks av. ___ 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"
Again two ADSL lines, routing problems
Hello. I have a setup where a FreeBSD box is connected to two ADSL routers: default gateway is set to the first and, in case of failure, is moved to the other one. This works perfectly for outgoing connections: in the event of the switch, I'll have to reconnect, but that's acceptable. The problem is in the incoming connections: if I get one on the "backup" router, this will reach the server, which will however answer through its "default" router. Thus the remote client will see packets coming back from a different host and things won't work. Just to be clear, the packets travel as follows (with source and dest IP in brackets): Client (x.x.x.x) -> Backup router (y.y.y.y) Backup router (x.x.x.x) -> Server (z.z.z.z) Server (z.z.z.z) -> Default router (x.x.x.x) Default router (v.v.v.v) -> Client (x.x.x.x) So the client (x.x.x.x) connects to y.y.y.y (the backup ADSL public IP), but gets answers from v.v.v.v (the master ADSL public IP). AFAIK there is no solution to this, but I tought I'd ask before giving my official opinion to my customer. Perhaps there's some sort of hack we could use, that through ipfw/natd/other diverting daemon/whatever delivers answers based on the MAC address of the incoming connections (if the MAC address belongs to the backup router, use that for answers)... does anyone know? bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Again two ADSL lines, routing problems
Artyom Viklenko ha scritto: You have to enforce simmetrical routing on your FreeBSD box. You can use, for example, PF firewall Using such options and features as labels and route-to/reply-to statemens. Also it is possible with ipfw, but I prefer PF. :) Thanks, this is interesting. However I failed to understand what you mean exactly. Do you have any pointer to a document that explains this? I searched in PF's and ipfw's manual, but found nothing that I could relate to this. Also, I'm right now using ipfw... bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Again two ADSL lines, routing problems
Eric F Crist ha scritto: > The biggest problem one would have with this sort of setup, is the upstream provider support. I don't know of any ISP's that are going to be willing or even able to propagate routes for your static IPs through their DSL systems. If you want that sort of redundancy and support, you'll probably have to go to a higher-end business class solution, such as a T1 or even possibly an ISDN line. In fact I was speaking about an hypotetical in-house solution. Some kind of stateful deamon on the line of natd that makes it so that if connection x comes from MAC address y, then answer through gateway z (the IP corresponding to MAC address y). bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Again two ADSL lines, routing problems
Josh Paetzel ha scritto: errrm, in pf I can give you a concrete example of how to deal with this. Thank you very much. Please see also my reply to Artyom. Your question seemed to imply that you don't want to load-balance or really even do round-robin NAT and you're fine with manually cutting over the default route in case a link fails, but the problem you are having is that the responses to incoming connections go out the default route, which doesn't work. Yes, this is the main problem. I might be interested in load-balance, but it's much less important. Besides, what I described is part of a larger setup, so this is already partly implemented. bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Again two ADSL lines, routing problems
Artyom Viklenko ha scritto: Very brief example (just to show main idea). Assume you have thre interfaces in router fxp0 - lan, fxp1 - adsl1, fxp2 - adsl2. fxp0 - 192.168.0.1, fxp1 - 192.168.1.2, fxp2 - 192.168.2.2 adsl1 - 192.168.1.1, adsl2 - 192.168.2.1 $server="192.168.0.2" $adsl1="192.168.1.1" $adsl2="192.168.2.1" pass in on fxp1 inet from any to $server keep state tag ADSL1 pass in on fxp2 inet from any to $server keep state tag ADSL2 pass out on fxp0 reply-to (fxp1 $adsl1) from any to $server tagged ADSL1 keep state pass out on fxp0 reply-to (fxp2 $adsl2) from any to $server tagged ADSL2 keep state This is just part of whole rulebase regarding your problem. Packets coming in via adsl1 will pass and got tagged by ADSL1 tag. Also, state will be created. Then packet will pass out to server, state will be created. and all replies from server will be frowarded back via adsl1. Same for traffic from adsl2. Thank you very much, this might do the trick. However, in your example the two ADSL routers are on separate interfaces, while in the setup I have there's only one external interface (and a switch). Would this work the same, by tagging based on MAC address? Even if the machine is not acting as a bridge? Should I create a bridge0 interface, even if it would actually not bridge anything? Besides, I don't really understand what fxp0 has to do with this: the box which is connected to the two ADSL is running the server, so in the above example $server would be 192.168.0.1 itself. If I understand correctly I should do something on the line of: $adsl1="192.168.0.1" $adsl1mac="aa:bb:cc:dd:ee:ff" $adsl2="192.168.0.2" $adsl2mac="gg:hh:ii:jj:kk:ll" //Tag based on MAC address pass in on fxp0 reply-to (fxp0 $adsl1) inet from any to $server tagged ADSL1 keep state pass in on fxp0 reply-to (fxp0 $adsl2) inet from any to $server tagged ADSL2 keep state One last question: could I use this, while still filtering with ipfw as I do now? Can the two firewalls cooperate? Would this be too much trouble (even if I have a non trivial ruleset working)? Someone can suggest a way with ipfw? I found this: http://archive.netbsd.se/?ml=dfbsd-users&a=2005-10&t=1361976 (the last message). It would involve creating a second net on the same ethernet segment, but I can live with that (altough it is going to be slightly more compilcated since I'm also using CARP). Any opinion on this? bye & Thanks av. bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Latest Samba patches
After portupgrading two samba servers, I cannot connect any more to them through mount_smbfs. Connecting from Windows works fine. Am I the only one who is experiencing this problem? bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Latest Samba patches
Per olof Ljungmark ha scritto: Andrea Venturoli wrote: After portupgrading two samba servers, I cannot connect any more to them through mount_smbfs. Connecting from Windows works fine. Am I the only one who is experiencing this problem? No, we are at least two :-) Ok, thanks. Any hint on when this will be fixed? Perhaps with the update to 3.0.27a? Not that I'm recriminating, I just need to plan either an upgrade in a short time or a downgrade. bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Routing problem with aliases
Hello. A box of mine has an interface configured with two IPs on two different nets: # ifconfig xl0: flags=8943 mtu 1500 options=9 inet 192.168.2.2 netmask 0xff00 broadcast 192.168.2.255 inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255 ether 00:50:da:77:5f:79 media: Ethernet autoselect (100baseTX ) status: active Then I have two gateways: 192.168.2.1 and 192.168.0.6. "ping 192.168.2.1" works correctly (source address 192.168.2.2 is used) "ping 192.168.0.6" also does (source address 192.168.0.2 is used) Setting 192.168.2.1 as my default gateway allows me to ping any host on the Internet (again source address 192.168.2.2 is used). However, if I set 192.168.0.6 as the default router, I can't reach the Internet, since it uses source address 192.168.2.2 and the next router won't obviously like it. Is this normal behaviour? Anything to set or check? Any other hint? Perhaps I should mention that I also have some carp devices on that interface, but I'm not sure whether it matters. bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Testing lagg
Hello. I've got a new box which features two gigabit ports and I though I'd try lagg with LACP. On the box I put the following in /etc/rc.conf: ifconfig_em0="up" ifconfig_em1="up" ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 192.168.100.101 netmask 255.255.255.0" Then I aggregated the ports on the switch (3com). This seems to work fine, although I see a 30 seconds delay from the moment a network cable is unplugged and the moment the network works again. Is this normal? Can this time be reduced? Any other hint or gotcha? bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Testing lagg
Gary Palmer ha scritto: Does the switch have spanning tree enabled? Yes. Should it be? bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bridge + ip_alias --> SLOW!!!
Hello, I've got a problem I cannot understand and hope someone can help me. I've got a machine which must firewall a whole class C subnet. The upstream router (100Mb/s fiber connection) is configured as xxx.xxx.xxx.254, so I've chosen xxx.xxx.xxx.1 for my box and bridge with the other xxx.xxx.xxx.* IPs (10Mb/s copper). (In all my tests I've setup the external NIC to 10Mb/s; I wouldn't do more anyway). ifconfig gives >fxp0: flags=8943 mtu 1500 >ether 00:02:b3:5e:5c:ca >media: Ethernet 10baseT/UTP >status: active >vr0: flags=8943 mtu 1500 >inet xxx.xxx.xxx.1 netmask 0xff00 broadcast xxx.xxx.xxx.255 >inet xxx.xxx.xxx.12 netmask 0x broadcast xxx.xxx.xxx.12 >ether 00:40:f4:77:5f:c8 >media: Ethernet 10baseT/UTP >status: active >fxp1: flags=8943 mtu 1500 >inet 192.168.106.1 netmask 0xff00 broadcast 192.168.106.255 >ether 00:02:b3:5e:61:d0 >media: Ethernet 100baseTX >status: active >vr1: flags=8802 mtu 1500 >ether 00:40:f4:77:61:c5 >media: Ethernet autoselect (none) >status: no carrier >lo0: flags=8049 mtu 16384 >inet 127.0.0.1 netmask 0xff00 vr1 is currently not used, fxp1 serves a private network, fxp0 and vr0 are bridged with the following: cat /etc/sysctl.conf >net.link.ether.bridge=1 >net.link.ether.bridge_cfg=vr0,fxp0 >net.link.ether.bridge_ipfw=1 >net.link.ether.ipfw=1 Notice I gave no IP to fxp0, since, from what I could understand, it is not needed. uname -a gives: >FreeBSD zz 4.10-RELEASE-p2 FreeBSD 4.10-RELEASE-p2 #7: Tue Aug 24 16:45:56 C >EST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ZZ i386 and we are using ipfw2: tail /usr/src/sys/i386/conf/ZZ >options IPFIREWALL >options IPFIREWALL_VERBOSE >options TCP_DROP_SYNFIN >options RANDOM_IP_ID >options IPDIVERT >options IPFW2 >options BRIDGE >options DUMMYNET As you can see vr0 also have an alias address (for reasons which are out of scope here) and with that the problem begin. I can achieve good speeds on the external side both ways (originating connections and working as a server) if I use xxx.xxx.xxx.1, but xxx.xxx.xxx.12 is MUCH MUCH slower! No difference can be noted on the internal net or the private net on fxp1. Just to give an idea, I tested with iperf and this are the results: internal net -> xxx.xxx.xxx.1 6.93 Mb/s internal net -> xxx.xxx.xxx.126.94 Mb/s internet -> xxx.xxx.xxx.1 237 Kb/s internet -> xxx.xxx.xxx.1260.3 Kb/s So using the alias IP seems four times slower, but this is probably due to the bandwidth limit on the other side (I could only test from an ADSL): if I surf the web, choosing one of the two IPs as source, I get a much bigger gap. I tried with an "allow all" rule as the first in the ipfw chain, and got no improvement, so the firewall should (IMHO) not be the problem. I'm really lost, I cannot see any reason for this difference. Any hint? bye & Thanks av. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bridge + ip_alias --> SLOW!!!
** Reply to note from "Chris Dionissopoulos[freemail]" <[EMAIL PROTECTED]> Tue, 31 Aug 2004 07:01:11 +0300 > Andrea, > Try something like this as alternative configuration: Thank you very much for the answer. Unfortunately I didn't want to mess remotely with this kind of configuration, so I waited until I could get my hands physically on the machine today. As I was explaining the matter to my customer, she happened to notice that the alias IP is no longer needed (was some kind of subscription); just wish she had told me *before* :) Alas, the machines fares good now with only xxx.xxx.xxx.1 and I don't like to experiment with a production machine, if it works. Still I don't know if the problem was FreeBSD or lied elsewhere, but I can't think of anything else, so it could be a good candidate for investigations, if I (or anyone else) ever happen to have a similar configuration to play freely with. Thanks a lot really. bye av. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic with 4.10p4 and ipfw2
Hello.
A box of mine, which acts as firewall/bridge, is experiencing frequent
panics.
As said in the subject line, it's a 4.10-RELEASE-p4 with ipfw2 enabled
in the kernel.
I've run through post mortem kernel analisys and found out that the
crashes are always related to ipfw2; specifically I get:
panic: free: multiple frees
Here is the complete backtrack:
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc0150993 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316
#2 0xc0150db8 in poweroff_wait (junk=0xc02354ac, howto=-1071427665)
at /usr/src/sys/kern/kern_shutdown.c:595
#3 0xc0208a3e in trap_fatal (frame=0xc023a3e4, eva=48)
at /usr/src/sys/i386/i386/trap.c:974
#4 0xc0208711 in trap_pfault (frame=0xc023a3e4, usermode=0, eva=48)
at /usr/src/sys/i386/i386/trap.c:867
#5 0xc02082fb in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = 0, tf_ebp = -1071406036, tf_isp = -1071406064,
tf_ebx = -1071330820, tf_edx = 6864896, tf_ecx = -1054588914,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071892584, tf_cs = 8,
tf_eflags = 66182, tf_esp = -967647568, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:466
#6 0xc01c3798 in acquire_lock (lk=0xc024c9fc)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:266
#7 0xc01c8e7c in softdep_count_dependencies (bp=0xc652deb0, wantcount=0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:4792
#8 0xc01cc0d8 in ffs_fsync (ap=0xc023a4a0)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:168
#9 0xc01cabab in ffs_sync (mp=0xc123fc00, waitfor=2, cred=0xc0a3e800,
p=0xc026dbe0) at vnode_if.h:558
#10 0xc0181737 in sync (p=0xc026dbe0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:583
#11 0xc015072e in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:235
#12 0xc0150db8 in poweroff_wait (junk=0xc0218cff, howto=-1051816704)
at /usr/src/sys/kern/kern_shutdown.c:595
#13 0xc014c41f in free (addr=0xc18fc100, type=0xc0249420)
at /usr/src/sys/kern/kern_malloc.c:385
#14 0xc01a56ce in lookup_dyn_rule (pkt=0xc023a650, match_direction=0xc023a5c8,
tcp=0xc0b26b50) at /usr/src/sys/netinet/ip_fw2.c:784
#15 0xc01a6ae7 in ipfw_chk (args=0xc023a630)
at /usr/src/sys/netinet/ip_fw2.c:1900
#16 0xc01aa5f5 in ip_output (m0=0xc0b26b00, opt=0x0, ro=0xd0bfb0fc, flags=0,
imo=0x0, inp=0xd0bfb0c0) at /usr/src/sys/netinet/ip_output.c:733
#17 0xc01afc51 in tcp_output (tp=0xd0bfb180)
at /usr/src/sys/netinet/tcp_output.c:953
#18 0xc01ae977 in tcp_input (m=0xc0b26b00, off0=20, proto=6)
at /usr/src/sys/netinet/tcp_input.c:2229
#19 0xc01a8f1c in ip_input (m=0xc0b26b00)
at /usr/src/sys/netinet/ip_input.c:934
#20 0xc01a8f7b in ipintr () at /usr/src/sys/netinet/ip_input.c:955
#21 0xc01fbd89 in swi_net_next ()
#22 0xc0156a69 in softclock () at /usr/src/sys/kern/kern_timeout.c:131
#23 0xc01fbd43 in doreti_swi ()
So, free is called from the following fragment:
/**
* lookup a dynamic rule.
*/
static ipfw_dyn_rule *
lookup_dyn_rule(struct ipfw_flow_id *pkt, int *match_direction,
struct tcphdr *tcp)
{
/*
* stateful ipfw extensions.
* Lookup into dynamic session queue
*/
#define MATCH_REVERSE 0
#define MATCH_FORWARD 1
#define MATCH_NONE 2
#define MATCH_UNKNOWN 3
int i, dir = MATCH_NONE;
ipfw_dyn_rule *prev, *q=NULL;
if (ipfw_dyn_v == NULL)
goto done; /* not found */
i = hash_packet( pkt );
for (prev=NULL, q = ipfw_dyn_v[i] ; q != NULL ; ) {
if (q->dyn_type == O_LIMIT_PARENT && q->count)
goto next;
if (TIME_LEQ( q->expire, time_second)) { /* expire entry */
=> UNLINK_DYN_RULE(prev, ipfw_dyn_v[i], q);
continue;
}
if (pkt->proto == q->id.proto &&
q->dyn_type != O_LIMIT_PARENT) {
I'm no kernel expert, so take my observation for what they might be
worth, but:
(kgdb) p *q
$24 = {next = 0xc18a2d00, rule = 0xc6523b3c, parent = 0xd0001,
pcnt = 13916504069872025600, bcnt = 11709303859986432, id = {dst_ip = 0,
src_ip = 0, dst_port = 15744, src_port = 49469, proto = 164 '\244',
flags = 129 '\201'}, expire = 0, bucket = 4294967295, state = 4294967295,
ack_fwd = 0, ack_rev = 0, dyn_type = 0, count = 0}
(kgdb)
These values do not make much sense to me... maybe the mess has already
happened?
Any hint?
Is ipfw2 known to be broken in 4_10? Should I upgrade to 4_STABLE?
Or is it just a matter of finding a better configuration for all the
relevant sysctl (which are all set to their default values)?
Really any help is appreciated!!!
bye & Thanks
av.
smime.p7s
Description: S/MIME Cryptographic Signature
ipfw verbosity
Hello. I noticed that when I issue "sh /etc/rc.firewall" to reload firewall rules from a remote console, I get disconnected (as I would expect) and locked out! The problems seems to be that "ipfw -f" prints: "command is /usr/local/...". This is in /usr/src/sbin/ipfw/ipfw2.c: fprintf(stderr, "command is %s\n", av[0]); This line does not onor the "-q" flag which, if I understand correctly, was exactly meant to allow this kind of operations without console access. Naturally, I can comment this line in my sources, but I was asking myself if this should be regarded as something to fix. bye & Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problems with latest freevrrpd.
Hello. I have two FreeBSD 4.11 boxes which have been using freevrrpd for a long time. Today I upgraded from 0.8.7 to 0.9.3 and since then I started having some problems. Specifically I started to see this messages on both boxes: freevrrpd[822]: ip ttl of vrrp packet isn't set to 255. Packet is discar ded ! Strangest thing is that this boxes are both dual-homed, and one side (fxp1 below) was working correctly, the other not (fxp0 below), meaning that both boxed grabbed all configured address (yes, both master and backup). I googled around and found out that someone was having the same problem, but no solution was provided. Since I was in a hurry, I grabbed the sources, commented this test out in vrrp_misc_check_vrrp_packet, and recompiled. Since then everything seems to work correctly, but I didn't have the chance to test failover yet (!!!). Comments and/or suggestions? Furthermore, I'm frequently seeing the following messages: freevrrpd[2188]: all errors are cleared on interface fxp1 freevrrpd[2188]: all errors are cleared on interface fxp0 Is this normal? Or something worth looking at? Here is my conf: [VRID] serverid = 1 interface = fxp1 priority = 255 addr = 192.168.0.4/32 password = x [VRID] serverid = 2 interface = fxp1 priority = 254 addr = 192.168.0.5/32 password = x vridsdep=4 [VRID] serverid=3 interface=fxp0 priority=255 addr=192.168.101.5/32 password=x [VRID] serverid=4 interface=fxp0 priority=254 addr=192.168.101.6/32 password=x vridsdep=1 The one on the other box is just specular, only one interface is fxp0, the other xl0. P.S. Please remove .diesmapper to reply. Sorry I have to do this :( ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WiFi and NFS
On 08/13/17 15:43, Grzegorz Junka wrote: Thanks a lot! That looks exactly like what I need. However, when I was checking the lagg configuration a few years ago, at that time it wasn't possible to set up a lagg with WiFi. Has anything changed (fairly) recently? Don't know about history, but I've been using that example possibly for a couple of years at least. bye av. ___ 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"
Help provisioning a Samba AD in a jail on ZFS
Hello.
As per subject, I'm building a new box which must host a jail running a
Samba AD, but I have trouble provisioning it.
Currently I'm trying samba44.
I read a lot of material and I think I understand the problem: it seems
the "samba-tool provision" script is incompatible with NFSv4ACL used by ZFS.
AFAICT this issue has been raised, the Samba team has acknowledged a
patch should be made, but so far nothing happened.
So I'm looking into workarounds:
a) someone suggest installing samba43, provision, then upgrade to
samba44. In fact this is some path I went through a couple of times in
the past (on UFS, however). Alas samba43 is no longer there.
b) I think I might get around this by provisioning with the deprecated
NTVFS, then switch to S3FS.
Unfortunately samba44 does not build NTVFS anymore, unless the DEVELOPER
option is used; but if the DEVELOPER option is used compilation (on
Poudriere) fails with:
../source4/lib/socket/socket_ip.c:864:12: error: comparison of array
'addr.__u6_addr.__u6_addr8' equal to a null pointer is always false
[-Werror,-Wtautological-pointer-compare]
if (addr.s6_addr == 0) {
~^~~~
/usr/include/netinet6/in6.h:103:29: note: expanded from macro 's6_addr'
#define s6_addr __u6_addr.__u6_addr8
^
1 error generated.
c) I tried creating a ZVOL, formatting it with UFS, mounting it with
ACLs inside the jail, but still provisioning says I have no ACL support.
d) I know samba46 is incompatible with jails (at least as AD DC), but
didn't try samba45. AFAICT, however, nothing should have improved WRT to
my problem.
So, after spending a couple of days on this and before spending another
week trying every path, I tought I'd ask...
Should I temporarily revive samba43?
Can samba44 with NTVFS compilation error be fixed?
Should I try samba45 or is it just a waste of time?
Would creating a jail on another (UFS) box and then moving
/var/db/samba4 and smb4.conf here work?
I'm open to any other suggestion as long as the objective (AD in a jail
on ZFS) is met in the end.
bye & Thanks
av.
___
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: Help provisioning a Samba AD in a jail on ZFS
On 11/02/17 08:09, Alexander Zagrebin wrote: В Wed, 1 Nov 2017 16:01:18 +0100 Andrea Venturoli пишет: It seems it's offtopic here, but I'll try to answer. Doh! I was going to write to -port, but wrote -net in the end... Sorry! To setup a new samba46-based domain controller on ZFS in jail (I'm using it with the VIMAGE) you can try following: I'm not using VIMAGE (at least not yet). 1. Rebuild the net/samba46 port with the attached patches (patch-librpc__idl__xattr.idl, patch-python__samba__provisioninit__.py) 2. Initialize new domain with the following command (the last two parameters makes magic): samba-tool domain provision --use-rfc2307 \ --host-name= \ --realm= \ --domain= \ --adminpass= \ --option="vfs objects = acl_xattr" \ --option="acl_xattr:ignore system acls = yes" 3. After successful provisioning, edit /usr/local/etc/smb4.conf: - remove or comment out vfs objects = acl_xattr acl_xattr:ignore system acls = yes - add the following: vfs objects = zfsacl nfs4:mode = special nfs4:acedup = merge nfs4:chown = yes 4. Execute `samba-tool ntacl sysvolreset` 5. Start samba Looks like it worked. Hope I don't get any suprise in the deployment phase... Thank you very much!!! It is not ideal solution, but it seems to be working, despite there are another resolvable issues (with BIND9_DLZ and so on)... I'm using internal DNS, anyway... I've sent patches to the port maintainer, but have no answer. Perhaps you could try and file a bug report? At the very least users would be able to find your patches. bye & Thanks av. ___ 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"
bridge0 not working when cable disconnected
Hello. I've got the following setup: re0: 192.168.x.1 (main IP) 192.168.x.2 (jail) 192.168.x.3 (jail) 192.168.x.4 (jail) tap0: VM-bhyve VM (using 192.168.x.9) bridge0: connecting re0 and tap0. The VM used to work properly. Now, however, I've got the network cable temporarily disconnected from re0 and the VM seems to be isolated: it can't reach 192.168.x.1 or any jail or anything else (192.168.x.1 is its gateway). tcpdump on tap0 or bridge0 show packets coming out of the VM, but no answer going in. Pinging 192.168.x.9 from the host yields "no route to host". Can the network cable disconnection be the reason? I'm asking here since the box is physically in another place and I cannot try this now, but would like to do some work before I go there. Any other hint, otherwise? bye & Thanks av. ___ 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"
[SOLVED] Re: bridge0 not working when cable disconnected
On 11/16/17 19:01, Eugene Grosbein wrote: If you add an interface to a bridge, you should remove all IP addresses from it and assign them to the bridge itself instead. And you will be fine. Thanks. In fact, assigning the base IP and all the jails to bridge0, instead of re0 solved. I still think bhyve assigns the VM's IP to tap0, but that doesn't seam to be a problem. bye av. ___ 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: [SOLVED] Re: bridge0 not working when cable disconnected
On 11/24/17 10:52, Vincenzo Maffione wrote: Hi, The VM IP is assigned to the emulated interface inside the guest OS (e.g. vtnet0). It would not make sense to assign an IP to tap0, and I'm quite sure bhyve doesn't do that. Right. Sorry for having expressed this with wrong wording. bye & Thanks av. ___ 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"
Questions about ipfw's dynamic rules' dyn_keepalive
Hello.
I'm trying to find out how dyn_keepalive works.
From ipfw(8):
net.inet.ip.fw.dyn_keepalive: 1
Enables generation of keepalive packets for keep-state rules on
TCP sessions. A keepalive is generated to both sides of the con-
nection every 5 seconds for the last 20 seconds of the lifetime
of the rule.
...
... For TCP sessions, dynamic rules can be
instructed to periodically send keepalive packets to refresh the state of
the rule when it is about to expire.
So I made some tests on a 11.1 router.
I made sure net.inet.ip.fw.dyn_keepalive=1 (which is the default, BTW),
activated some rules and made some tests with tcpdump to see if
keep-alives were sent.
Test 1: connection to the router itself
I added this rule on the router:
ipfw add 99 allow tcp from any to me http setup keep-state
Then, from another box (FreeBSD client without ipfw or other firewall) I
issued:
telnet router 80
I watched the dynamic rule being created, then waited 4.5 minutes and
saw the keep-alive packets flowing and the rule timer get back to
{net.inet.ip.fw.dyn_ack_lifetime} before reaching 0.
The connection would still work after several minutes.
Test 2: connection through the router
ipfw add 99 allow tcp from any to external-host http setup keep-state
Then, from the same box as before I issued:
telnet external-host 80
(external-host is is also FreeBSD with ipfw stateful rules).
The result is the same as in test 1 (i.e. the connection will persist).
Test 3: let's introduce NAT
ipfw add 99 skipto 1 tcp from any to external-host http setup keep-state
(skipto 1 is used to allow nat rules).
With the same external host as before, now the rule times out!
Test 4: fwd to a jail on the router itself
ipfw add 99 fwd 127.0.2.1 tcp from any to me http setup keep-state
telnet router 80
Again I see the keep-alive packets flowing and the connection will persist.
Test 5: fwd to a jail on the router itself but using a different IP
ipfw add 99 fwd 127.0.2.1 tcp from any to x.y.z.w http setup keep-state
telnet x.y.z.w 80
This time no keep-alives and the rule times out.
I tried reasoning on this, but could not come up with an explanation.
Can anybody give any hint about the above behaviours or point me to good
documentation? The man pages is very brief on this, unfortunately.
bye & Thanks
av.
___
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: Questions about ipfw's dynamic rules' dyn_keepalive
On 04/03/18 12:54, Andrey V. Elsukov wrote: On 03.04.2018 13:45, Andrey V. Elsukov wrote: Can anybody give any hint about the above behaviours or point me to good documentation? The man pages is very brief on this, unfortunately. Hi, Thanks for your answer. ipfw uses M_SKIP_FIREWALL flag for self-generated packets. Thus keep-alive packets are sent bypass the rules. When you use NAT, I guess keep-alive packets have private source address, because they are not go through the NAT rule. And because of this remote host drops them without reply. If this is the reason, since I run tcpdump on the client (internal network) I should have seen them arriving, shouldn't I? You can try this patch: https://people.freebsd.org/~ae/ipfw_bypass_own_packets11.diff It adds sysctl variable net.inet.ip.fw.bypass_own_packets, that can control the behavior of M_SKIP_FIREWALL flag. It seems this is a patch against HEAD and it doesn't apply cleanly to 11.1R. Unfortunately the file it modifies seems to have changed a lot and I don't know how to adapt this. Is there a plan to get this patch in the source in the future? If not, why? Are there any disadvantages? bye & Thanks av. ___ 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"
Proxy a TCP connection
Hello. Let's say I have a router connected to the Internet on one side and to a LAN with private IPs on the other. I want some clients from outside to be able to connect to a TCP service on a machine on the LAN: they should connect to port X on the firewall's public IP and reach port Y on the internal box. I've used net/socket in the past, but stopped when, in some corner case, it would "ruin" the data; besides it has been removed from the port tree. I happily switched to net/tcpproxy, but lately it's dying every few days and must be restarted; I could drop its rc.d script and use sysutils/daemontools' svscan instead, but if there's a simpler solution... Does anyone have a good suggestion for a program similar to the above ones? I require nothing fancy, I just want it to be reliable. bye & Thanks av. ___ 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: Proxy a TCP connection
On 05/19/18 03:10, Eugene Grosbein wrote: You don't need any additional software at all. Just instruct FreeBSD kernel to do what you need, it will do that just fine. Thanks. In fact I've used ipfw nat in the past, but I'd rather use a userland daemon: doing things at rule level makes it more easy to screw everything up and lock myself out. Additional advantage of this approach is that internal hosts will see real public IP address of connecting external host instead of your own. This is exactly what I don't want, as, unfortunately, we have some devices which will refuse connections unless they come from their own subnet. bye & Thanks av. ___ 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: Proxy a TCP connection
On 05/19/18 00:08, Reshad Patuck wrote: Hi, If you are running pf or ipfw on your router you could use a forward rule to forward connections that come in on a certain internet IP and port to a select internal IP or port. Thanks. I'm in fact using ipfw, but already have quite a complex rule set and I'd rather avoid messing with it further. If you don't have a firewall running and can install ports on your router have a look at relayd, it should do what you want. Do I understand correctly that it's a front-end to pf? So kernel level again? bye & Thanks av. ___ 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: Proxy a TCP connection
On 05/21/18 13:16, Luciano Mannucci wrote: On Fri, 18 May 2018 23:29:33 +0200 Andrea Venturoli wrote: Does anyone have a good suggestion for a program similar to the above ones? I require nothing fancy, I just want it to be reliable. The oldest, the simplest, the most reliable (I'm still using it, and it shoud be in the ports): Peter da Silva's plugdaemon I'm using it since last century... Luciano. Thanks to anyone who answered. I'm currently trying net/bounce, as suggested by Eugene. If that won't work properly, I'll sure give plugdaemon a shot. bye av. ___ 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: Proxy a TCP connection
On 05/21/18 18:10, Andrea Venturoli wrote: Thanks to anyone who answered. I'm currently trying net/bounce, as suggested by Eugene. If that won't work properly, I'll sure give plugdaemon a shot. Just an update in case anyone is interested... Bounce is still dying occasionally; in some way it is better than tcpproxy, in that it uses different process, one for each port, so when one dies, the other ports will still work (when tcpproxy dies, all port redirections stop working). I still haven't managed to understang why it dies: really no clue is in the log... It's always the same port (same device) and once I had to tcpdrop a FIN_WAIT2 connection in order to be able to restart it. Guess I'll have to get daemontools' svscan out again. bye & Thanks av. ___ 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: Questions about ipfw's dynamic rules' dyn_keepalive
On 04/03/18 12:54, Andrey V. Elsukov wrote:
On 03.04.2018 13:45, Andrey V. Elsukov wrote:
Can anybody give any hint about the above behaviours or point me to good
documentation? The man pages is very brief on this, unfortunately.
Hi,
ipfw uses M_SKIP_FIREWALL flag for self-generated packets. Thus
keep-alive packets are sent bypass the rules. When you use NAT, I guess
keep-alive packets have private source address, because they are not go
through the NAT rule. And because of this remote host drops them without
reply. Since there are no replies to keep-alive requests, a state times
out.
You can try this patch:
https://people.freebsd.org/~ae/ipfw_bypass_own_packets11.diff
It adds sysctl variable net.inet.ip.fw.bypass_own_packets, that can
control the behavior of M_SKIP_FIREWALL flag.
Hello.
Now that this patch applies cleanly to 11.2, I tried it.
After setting net.inet.ip.fw.bypass_own_packets to 0, I run the same
tests again: unfortunately nothing seems to have changed... I only see
keep-alive packets when there's no NAT or FWD rule involved.
Is anything more required besides patching, recompiling the kernel and
tuning the sysctl? Perhaps this setting must be done on boot and cannot
be enabled later or something like that?
For wishmaster:
Since you said it works for you, can I ask which FreeBSD version you
tested this on? Do you have any other patch or specific setup? How did
you test this?
Thanks a lot to anyone
Andrea Venturoli
___
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: FCP-0101: Deprecating most 10/100 Ethernet drivers
On 10/4/18 3:07 PM, Warner Losh wrote: At the root of this problem is the community's long resistance to having data reported back to the project data about the machines running FreeBSD. Absent any real and significant data, the only way to know if things are unused is to ask. We cannot have the act of merely asking cause people to freak out and hurl expletives all over the place. That's significantly not cool. First off, I absolutely don't want to flame: I'm glad you asked and I was happy to answer. Just out of curiosity, don't we have sysutils/bsdstats (which I install on all the boxes I manage, but I understand won't be present in most embedded systems)? Is that project such a failure? If so, should it be better promoted or would it be pointless? bye & Thanks av. ___ 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"
CARP troubles with 10.x
Hello. I've been using CARP for years and I'm only getting troubles since a week or so. My setup is as follows: |re0=10.1.2.13/10.1.2.127 fw1 fxp0=192.168.124.3| |client re0=10.1.2.18| --- --- |192.168.124.1 router WAN| |re0=10.1.2.15/10.1.2.127 fw2 fxp0=192.168.124.2| Client, fw1 and fw2 are FreeBSD 10.3 with the latest patches. On fw1 I have: ifconfig_re0="inet 10.1.2.13 netmask 255.255.255.0" ifconfig_re0_alias0="vhid 1 advskew 100 pass xx inet 10.1.2.127" ifconfig_fxp0="inet 192.168.124.3 netmask 255.255.255.0 -tso" On fw2 I have: ifconfig_re0="inet 10.1.2.15 netmask 255.255.255.0" ifconfig_re0_alias0="vhid 1 pass xx inet 10.1.2.127" ifconfig_fxp0="192.168.124.2 netmask 255.255.255.0 -tso" "client"'s gateway is 10.1.2.127. Problem is, I start ssh sessions to some external hosts from "client"; fw1 and fw2 run stateful ipfw rules and ssh is configured to use keep-alives. After a while my ssh session will stop responding and later time out; restarting them works immediately (for a while). Digging the two firewalls' logs, I saw that the connections normally go out through fw2 (which is expected due to advskew on fw1), but at some point will switch to fw1 for no reason (no network event I'm aware of has happened). Nothing is in the logs about a CARP status change on both fw1 and fw2 (net.inet.carp.log=1). Any help is appreciated, but first thing that puzzles me is that "tcpdump -l -i re0 carp" shows absolutely nothing. Shouldn't this log the CARP advertisement packets? bye & Thanks av. ___ 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"
Some questions about in-kernel NAT
Hello. I'm using "ipfw nat" on several 10.3 boxes, but I have some questions. Let's start with a simple one: how do I list configured NATs and their details? I know I can configure a NAT with "ipfw nat 1 config ...", but how do I show what I did? Second question: _ if I issue "ipfw nat 2 config if re0", I'll see the output "ipfw nat 2 config if re0"; _ if I issue "ipfw nat 2 config ip 192.168.0.1", I'll see the output "ipfw nat 2 config ip 192.168.0.1"; _ however if I issue "ipfw nat 2 config if re0 ip 192.168.0.1", output will be "ipfw nat 2 config if re0". Does this mean the "ip" part was ignored? Are "if" and "ip" mutually exclusive? I don't think this is mentioned in the man page... Let's get to my problem now: _ at boot, my re0 interface is configured with IP 192.168.0.1, along with an alias (192.168.0.2); _ my ipfw rules get loaded, issuing a "nat 2 config ip 192.168.0.1" command; _ after that ezjail is started, featuring a jail on 192.168.0.3. From this point on, my aliased packets go out with 192.168.0.3 as source address. I have to manually run "ipfw nat 2 config ip 192.168.0.1" again, in order to have them correctly going with the desired IP. How can I avoid this (and eliminate the need of manual intervention after each boot)? Of course I could use some trick, like writing a rc.d script that runs after ezjail's, but I'd like to understand and solve (not work around) :) TIA. bye av. ___ 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: Some questions about in-kernel NAT
On 03/08/17 18:03, Freddie Cash wrote: It's listed in the EXAMPLES section of the ipfw(8) man page. ipfw nat show config <-- view config for all nat instances ipfw nat 123 show config <-- view config for nat 123 ipfw nat 111-999 show<-- view logs for nat 111-999 Oops!!! Been working too much, lately. Sorry for overlooking this section and posting some noise. Let's get to my problem now: _ at boot, my re0 interface is configured with IP 192.168.0.1, along with an alias (192.168.0.2); _ my ipfw rules get loaded, issuing a "nat 2 config ip 192.168.0.1" command; _ after that ezjail is started, featuring a jail on 192.168.0.3. From this point on, my aliased packets go out with 192.168.0.3 as source address. I have to manually run "ipfw nat 2 config ip 192.168.0.1" again, in order to have them correctly going with the desired IP. What's the ipfw command that's run at boot time? Sounds like it's configured to use the interface address instead of a specific IP address. Yes and no: it uses both, i.e. "ipfw nat 2 config if re0 ip 192.168.0.1". However, later only the interface is listed from the show command; i.e.: # ipfw nat 2 show config ipfw nat 2 config if re0 Guess I'll have to use the "ip", not "if" then. bye & Thanks av. ___ 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: OpenVPN and policy routing
On 03/30/17 05:22, Victor Sudakov wrote: Dear Colleagues, Anyone experienced with OpenVPN on FreeBSD? What would be the best way to policy route a network into OpenVPN? A routing decision must be based on the src IP address, not the dst IP address. Imagine an OpenVPN client with 3 interfaces: fxp0 is the outside interface towards the OpenVPN server, fxp1 is for LAN1 and fxp2 for LAN2. From LAN1, some private networks are reachable through OpenVPN (tun0), this is done via the regular route commands (pulled from the OpenVPN server). From LAN2, *everything* should be reachable only through OpenVPN. Which is the best way to accomplish this? Possibly pf's "route-to" rules: I've used those in the past, but as I've reported, sometimes pf gets stuck and only stopping and starting it again unblocks the network. Other ideas could be jails or setfib, but I've not thinked those out. Maybe other people will come up with smarter ideas. bye av. ___ 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: OpenVPN and policy routing
On 03/30/17 09:46, Victor Sudakov wrote: Will "ipfw fwd" do the trick? I could "ipfw fwd" the packets into the tun0 interface, but will OpenVPN understand that? Never tried this, sorry. bye av. ___ 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: WiFi and NFS
On 08/13/17 13:47, Grzegorz Junka wrote: On my laptop I have two interfaces, wlan0 (WiFi) and ue0 (LAN). Obviously LAN is faster but not always connected. Is there any way to tell the system to use LAN interface in preference to the other? You mean: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html#networking-lagg-wired-and-wireless ? bye av. ___ 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: Two or more exports files, is it feasible?
On 2019-10-29 03:57, Thomas Mueller wrote: Is is possible to have two or more /etc/exports files, using different names of course? While I cannot answer your question... One possible scenario is having one exports file for NFS 4 and one for NFS3, for clients that don't support NFS 4? ... I used to have both NFSv3 and NFSv4 exports in the same file, back before I completely got rid of NFSv3. Are you having problems doing this? bye av. ___ 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"
net.inet.tcp.pmtud_blackhole_detection
Hello. Running 11.3, is there any risk or downside in enabling this? I cannot reach my homebanking otherwise; I think either the bank has completely disabled ICMP or some router in between filters it. I see it's not enabled by default: is it just out of precaution? bye & Thanks av. ___ 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"
Help with VNET
Hello. I've been using jails for years with ezjail. Now I'm trying to experiment with VNET. I've looked for a tutorial, but found scarce (and possibly outdated) info. Box is a 12.1/amd64. Basic configuration involves wlan0 configured via DHCP (192.168.133.26). Host networking works. For a start, let's get IPFW out of the way: #ipfw add 1 pass ip from any to any Then I setup the host: # ifconfig epair create (Now I see epair0a and epair0b) # ifconfig bridge create up # ifconfig bridge0 addm wlan0 addm epair0a Now I start the jail and I don't see epair0b anymore on the host. In the jail I issue: #ipfw add 1 pass ip from any to any #ifconfig epair0b 192.168.133.27 Now: _ pinging the host from the jail works; _ pinging the jail from the host works; _ pinging another host from the base system works; _ pinging another host from the jail does NOT work. tcpdump on wlan0 shows ARP packets from the jail (who tries to get the MAC address of the external host), but these do not reach the network (a tcpdump on the external host doesn't show them). IPFW logging shows that it's not blocking anything. Any hint? bye & Thanks av. ___ 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: Help with VNET
On 10/21/20 12:19 PM, Goran Mekić wrote: Did you setup NAT? No. Should I? Why? The IP I gave to the jail is in the same subnet as the host. BTW, I have similar (working) setups with bhyve (using tap instead of epair) and I didn't setup NAT there. bye & Thanks av. ___ 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: Help with VNET
On 10/21/20 12:20 PM, Kristof Provost wrote: This is your problem. You can’t bridge over wifi interfaces. > That’s a limitation of station mode wifi. I had the suspect... Is this documented somewhere? Is this a bug or feature? Try routing, or try with a wired interface. I'll try and get back if that doesn't work. bye & Thanks av. ___ 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"
net/realtek-re-kmod panics with debug kernel
Hello. I've got a 12.2/amd64 desktop pc with the following on the motherboard: re0: port 0xe000-0xe0ff mem 0xf7404000-0xf7404fff,0xf740-0xf7403fff irq 33 at device 0.0 on pci4 Unfortunately it's not easy to plug a new PCI NIC into it, and since re0 tends to hang on load, I'm using the driver from ports. (See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208205) Yesterday I compiled a kernel with all debug features in order to analyze some (probably unrelated) deadlock. Alas, with such features enabled, the machine panics at boot with: _mtx_lock_sleep: recursed on non-recursive mutex re0 0 if_re.c:7085 I don't have full data now, but I can reproduce and try to get it, if it's useful. Is it worth opening a bug report? bye & Thanks av.
Re: net/realtek-re-kmod panics with debug kernel
On 6/8/21 9:16 AM, Alex Dupre wrote: Just to be sure, have you recompiled the kernel module with the same sources as the new debug kernel? Sure! If so, probably the best location to open a bug report might be here: https://github.com/kostikbel/rere/issues Done! bye & Thanks av.
Some strangeness with CARP
Hello. I've set up a network with CARP and I think I'm seeing something strange. What follows is a simplified setup (the real one involves lagg and vlan, but this should not matter). I have a Zyxel managed switch, two "servers": - A 192.168.0.1 - B 192.168.0.2 and two "clients" - C 192.168.0.10 - D 192.168.0.11 Now let's add the "shared" CARP IP 192.168.0.3 (vhid 1) to server A and server B and start sniffing on C and D. If C or D talks with A or B using their own IP (192.168.0.1/192.168.0.2) the other client does not see that traffic (as is to be expected on a switched network). However if any client talks with the CARP IP (192.168.0.3) every node on the LAN can sniff that traffic! I tracked this down to the switch not learning the MAC address 00:00:5e:00:01:01 (which is what CARP vhid 1 uses), so every outgoing packet is broadcast to the whole network. Is this normal??? Changing to any other VHID (I tried 2, 4 and 10) does not show the same problem, as 00:00:5e:00:01:xx will show up in the switch MAC database. I'm scrapping my head trying to find an explanation, but so far I could only think the switch is misbehaving. Or am I missing some info and there's a reason for this? bye & Thanks av.
Re: Some strangeness with CARP
On 2/12/22 13:38, Michael Gmelin wrote: Maybe the switch or something it’s connected to uses vrrp? The switch has no options about VRRP, AFAICT (unless it can be called by a different name) and I don't think any other device could use VRRP. When using vhid 1, can you see any vrrp traffic using tcpdump You mean "tcpdump vrrp"? In that case I see CARP advertisements, as CARP is using the same protocol number as VRRP. bye & Thanks av.
Re: Some strangeness with CARP
On 2/13/22 05:34, Thomas Steen Rasmussen wrote: This is absolutely not normal. VHID 1 usually acts the same as the other VHIDs. I also suspect your switch. What is even stranger is that: _ if I boot with VHID 10, then add a different IP with VHID 1, I see both MACs in the switch database; _ if I boot with VHID 1, then add VHID 10, I see none of the two! Guess it's time to check with the vendor. bye & Thanks av.
Re: Some strangeness with CARP
On 2/13/22 11:17, Harry Schmalzbauer wrote: Hi, if source address of the SYN-ACK reply between [C|D] -> carpIP is .3/0:0:5e:00:01:01, Not sure I understand. What's .3? (mac adress learning limit set for the port(s) in question?!?). There's scarcely 10 entries in the whole MAC database (for all ports and all VLANs). Then again why :2, :4 and :10 yes, :1 not then? But maybe [A|B] respond with wrong source MAC address, depending on the VHID? But I see the correct data in the clients' MAC cache, so I guess they are answering correctly. bye & Thanks av.
Re: Some strangeness with CARP
On 2/13/22 11:51, Michael Gmelin wrote: According to their web site, some of their switches have support (don’t know your model) under IP Application > VRRP > Configuration. No such thing here (it's a GS1900-24E). Good luck getting to the bottom of this! Thanks. I could give up VHID 1 and just use any other number, but, at least initially, I'll try and check with the vendor out of curiosity. bye av.
Re: Some strangeness with CARP
On 2/13/22 12:20, Andrea Venturoli wrote: I could give up VHID 1 and just use any other number, but, at least initially, I'll try and check with the vendor out of curiosity. Just for the record: I opened a ticket with Zyxel a month ago and got practically no answer yet. bye av.
Meditation on rl driver
Hello. I'd like to share some thought on what happened to me: I had an external ADSL modem from Alcatel connected (with a straight cable, since the device has a reversed ethernet port) to a RealTek card on a FreeBSD 4.1-RELEASE box. I used the simple line in rc.conf: ifconfig_rl1="inet 10.0.0.6 netmask 255.0.0.0" Everything would work for a while, but under heavy load the modem would hang so bad it had to be cycle-powered, because it wouldn't communicate anymore (the led on its ethernet port would turn off). After trying a lot of things and reading the modem manual over and over I saw that they required the ethernet card on the computer to be set to half-duplex. So I issued an ifconfig and saw that the card was set to media autoselect (NONE). I tried with ifconfig rl1 inet 10.0.0.6 netmask 255.0.0.0 media 10baseT/UTP mediaopt half-duplex but it would not accept the last parameter. I ended up with the following in rc.conf: ifconfig_rl1="inet 10.0.0.6 netmask 255.0.0.0 media 10baseT/UTP mediaopt -full-duplex" and now everything works fine. My wonderings are: _ "mediaopt full-duplex" does not work, while it's documented in the rl man page; isn't this a bug? _ autoselecting the media obviously does not work correctly, does it? _ if two devices are connected and one speaks half-duplex, the other full-duplex, shouldn't they fail to communicate at all? Is the hang-up after a while and under heavy load normal? _ has anything changed in the rl driver after 4.1-RELEASE? I also hope this might help other people... Bye & Thanks av. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Meditation on rl driver
** Reply to note from Clark Gaylord <[EMAIL PROTECTED]> Thu, 8 Feb 2001 12:46:06 -0500 > It used to be the case that mediaopt half-duplex worked. It stopped > working at some point (I don't recall exactly when ... somewhere > between 4.0 and 4.2 I think), So this IS a bug. > but it seems that this is the default > (as it should be) if you specify 10baseT/UTP. Just wish the man page would say this. > I would be concerned > that the -full-duplex setting might actually be setting to *use* > full-duplex, not turn it off. Check the src on this; clearly the > man page is just plain wrong. Well, it's been working for a couple of weeks now, so I guess -full-duplex turns it off. > > _ autoselecting the media obviously does not work correctly, does it? > > Autoselect of duplex gets it right, in general, about 51.045% of > the time, and should be considered an Evil Spawn of Satan (ESS). Did not know this. I always used autoselect in a lot of computers with various OSes and different NICs, and this is the first time I had any problem. > When you say full-duplex doesn't work are you saying that the driver > barfs at the mention of it or that your NIC does not work properly > when it is set (which is correct, as your modem is hdx). I don't remember the exact message (and I don't have the box here now), but it was ifconfig that just refused the option (seemed that it could not get the driver to accept it). > Does it > accept the parameter when the card is set to 100 (while fdx 10 does > exist, it is less common, and I have seen drivers/NICs that only support > fdx at 100Mbps)? Didn't have the chance to try. Bye & Thanks av. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
