Re: removing RIP/RIPng (routed/route6d)
<> That's been a very workable system. p vixie On May 17, 2024 21:32, "Rodney W. Grimes" wrote: > Scott writes: > > Anyway, fun's over. Perhaps this is a greater lesson that the Foundation > > provide the rules under which code is added or removed from base and then > > we'd all be the wiser. > > The FreeBSD Foundation does not set project policy, the FreeBSD Core > Team does. Sadly that was never my intent when I created the original "Core", the core team was to help the developers in setting project policy based on there inputs and interactions, not to just elect some group of people and then bow down to them for all decisions. The DEVELOPERS as a whole is who should be setting all project policies. -- Rod Grimes rgri...@freebsd.org
Re: removing RIP/RIPng (routed/route6d)
i think it's not too soon for the bsd community to become less reactionary. (yes, i know that's ironic coming from me.) https://nomadbsd.org/ i'd like freebsd to be fit for a lot of purposes. a complete OS is one of those that i will use the most. but not the only one for me, and not the only one for the community. take deep breaths. re: John Howie wrote on 2024-05-15 19:04: FreeBSD (and BSD Unix in general) has a rich history of being a “complete” OS – kernel and userland. If there was really a demand for a minimalist version of FreeBSD, why have people not forked FreeBSD and created it by now? There is also nanobsd, as an option, for those that want minimalist installs (yes, I know it is meant for embedded systems, but it works). I think we need to stop trying to find solutions for non-existent problems. *From: *owner-freebsd-...@freebsd.org on behalf of Marek Zarychta *Date: *Wednesday, May 15, 2024 at 11:19 AM *To: *freebsd-net@freebsd.org *Subject: *Re: removing RIP/RIPng (routed/route6d) Today Michael Sierchio wrote: There is an argument to be made that all such components of the "base" system should be packages, and managed that way. That would facilitate removal or addition of things like MTAs, Route daemons for various protocols, etc. and permit them to be updated independent of the base system. Too much is included by default in Base. FreeBSD is a comprehensive OS, and most users still do appreciate this feature. I remember that we had also RCS tools in the base system, they got purged (moved to the ports tree really), most users are fine with it, but for managing single config files RCS is still the best-suited versioning system. We still have ftpd(8), but it was almost removed, there was a strong battle on the mailing list to preserve it. FTP protocol is as old as BSD, but it's still valid and, so far not deprecated. A similar story was with smbfs(5). The same probably applies to RIP/RIPng. What if we would better remove LLVM from the base if the system is bloated ? LLVM needs frequent updates and keeping it in base is far more risky in terms of system security than keeping RIP daemons. Why do we still have odd tools like biff(1) in the base ? On the other hand, for a significant share of the user base, the more tiny the OS is, the better. The transition to PkgBase should fulfill user needs, especially those, who want a minimalist OS. So please, go ahead and switch to PgkBase if your FreeBSD system contains undesired software. Cheers Marek On Wed, May 15, 2024 at 1:01 PM John Howie mailto:j...@thehowies.com>> wrote: I use RIP all the time. Removing it would be a pain. What is the justification? Moving it to ports is an option, but now we have to compile, distribute, and install it. Sent from my iPhone > On May 15, 2024, at 07:40, Tomek CEDRO mailto:to...@cedro.info>> wrote: > > On Wed, May 15, 2024 at 4:20 PM Scott mailto:uatka3z4z...@thismonkey.com>> wrote: >>> On Mon, Apr 15, 2024 at 09:49:27PM +0100, Lexi Winter wrote: >>> (..) >>> i'd like to submit a patch to remove both of these daemons from src. if >>> there's some concern that people still want to use the BSD >>> implementation of routed/route6d, i'm also willing to submit a port such >>> as net/freebsd-routed containing the old code, in a similar way to how >>> the removal of things like window(1) and telnetd(8) were handled. >> >> I use RIPv2 for it's simplicity and small memory and CPU requirements. It >> has its place and shouldn't be considered "legacy" despite its shortcomings. >> It's not uncommon for vendors like Cisco to produce "basic" feature sets of >> IOS that do not include any link-state protocols. >> >> Anyway, I'm a user, albeit a small user, of RIP and wouldn't object to its >> removal from FreeBSD if there were a small footprint alternative. I've used >> FRR and VyOS a bit and they are overkill as replacements. >> >> Your email doesn't justify its removal other than to say you are unconvinced >> of the value of shipping it. As a user I definitely see the value. I >> understand that there is always a cost to providing code, but that wasn't >> suggested as a reason. All APIs, modules, utilities, etc. need to regularly >> justify their presence in the OS. >> >> If it must be removed, is there any way to fork the FreeBSD routed and >> route6d to a port? Or would that defeat the purpose of removing it in the >> first place? > > Yeah, where did that recent trend came to FreeBSD to remove
Re: Source IPv4 address selection vs BGP IX connection
agreed. and one of my mods to the ultrix (~4.3bsd) kernel for gatekeeper.dec.com back in ~1990 was to use the result of gethostid(3) if that result was nonzero and if a socket was not already bound. so named(8) and ntpd(8) and anything else that used explicit binding got what they expected, but the vast majority who just used INADDR_ANY (or more often just bzero(3)'d the sockaddr) would get what the sysadmin wanted. multihoming wasn't well understood and has gotten worse since. of course, gethostid(3) is now deprecated in favour of sysctl(3), and the hostid(8) command is gone, and there's now more than one flavour of Internet-capable UNIX in the world, and there's more than one Internet address family now. so what i did in 1990 is a guide only inasmuch as some way should exist to change the default local address of a socket so that it isn't the address of the interface used for the destination. if that happens i hope we coordinate with Linux and with the other BSD's. Gregory Shapiro wrote on 2024-04-24 11:00: I still see value in source IP selection, even outside of the IX use case. -- P Vixie
Re: ixl(4) bhyve(8) SR-IOV with Transparent VLAN associated w/ VF's
On Wed, Apr 17, 2024 at 10:04 PM Lexi Winter wrote:
> Paul Procacci:
> > I'm assigning VF's to bhyve with pci passthru.
> [...]
> > Given this, I figured the best option would be to set the VLAN on the VF
> on
> > the host prior to handing it off to the bhyve instance effectively
> enabling
> > transparent vlans.
> [...]
> > Has anyone done this? Does anyone have any pointers to accomplish this?
>
> i looked into this a while ago and concluded that it's not supported, at
> least on Intel cards.
>
> my recollection is that someone was working on this at one point, but
> never finished it -- unfortunately, i can't remember who that was...
>
> you may be able to work around this by running vlan(4) on the VF on the
> host instead of passing the interface to the guest, but then you lose
> most of the benefits of using SR-IOV to begin with. i have run into
> some odd bugs with both SR-IOV and vlan(4) on ixgbe cards and would
> definitely recommend testing that thoroughly before deploying it.
>
That's a real bummer. You'd think this would be kinda a thing considering
the security implications.
Welp, Thanks for writing back Lexi!
~Paul
--
__
:(){ :|:& };:
ixl(4) bhyve(8) SR-IOV with Transparent VLAN associated w/ VF's
Hey all,
Strange one here. Not much on the internet that I could find.
I'm assigning VF's to bhyve with pci passthru.
Doing this allows the bhyve instance maintainer to set their own vlan and
I'd like that not to be the case for various reasons. One being I don't
need/want their traffic to potentially hit/sniff other traffic on any other
vlan than the one assigned to them.
Given this, I figured the best option would be to set the VLAN on the VF on
the host prior to handing it off to the bhyve instance effectively enabling
transparent vlans.
Unless I misreading ixl(4) which is a real possibility, it supports 'VLAN
tag insertion/extraction'.
Has anyone done this? Does anyone have any pointers to accomplish this?
Thanks,
Paul
--
__
:(){ :|:& };:
Re: Network starvation question
ipfw firewalling for bhyve host, bypassing bhyve guests
You don't need L2 for this. The firewall pattern when your bare metal host has an address in the vlan you use for guests is: Allow the specific things you want the bare metal host to do; Deny all else involving the bare metal host; Allow all else involving the guest subnet. p vixie On Oct 15, 2023 07:14, void wrote: Hello, My objective is to protect services on a bhyve host, while allowing traffic to the bhyve guests to pass to them unprocessed, as these each have pf and their own firewall policies. The host running an up-to-date 13-stable. I know ipfw can process both layer 2 and layer 3 traffic, but pf only processes layer 3 so that is why i want to use ipfw on the bhyve host. So we have bridge0 with igb0 tap0 and tap1 as members. In this example, igb0 has a mac address of 11:11:11:11:11:11 tap0 has 22:22:22:22:22:22 tap1 has 33:33:33:33:33:33 How can I tell ipfw to pass 22:22:22:22:22:22 and 33:33:33:33:33:33 and apply no more rules to frames matching those MACs? Let's say I want to just block on 11:11:11:11:11:11 (igb0) port 22 apart from 10.0.0.0/24 22:22:22:22:22:22 passing unhindered, unprocessed. Possible? --
propagating interface FIB to PCB
ed maste pointed me here after he saw me post the following on twixter:> to be clear, i can fix this and submit a patch, but won't if there are reasons why it was kept this way. -- P Vixie
net.add_addr_allfibs=0 is ignored in loader.conf
G'Day, I run to strange problem, I can't set net.add_addr_allfibs=0 via loader.conf. It seems to be ignored. After reboot net.add_addr_allfibs is set to 1. # sysctl net.add_addr_allfibs net.add_addr_allfibs: 1 I can set it to 0 manually via sysctl. Did anyone seen similar behaviour on 12.2? It is nearly fresh install. # uname -a FreeBSD gateway 12.2-RELEASE-p1 FreeBSD 12.2-RELEASE-p1 GENERIC amd64 - # cat /boot/loader.conf comconsole_speed="115200" console="comconsole" amdtemp_load="YES" net.add_addr_allfibs=0 net.fibs=3 - # cat /etc/rc.conf hostname="gateway" ifconfig_igb0="DHCP" ifconfig_igb0_ipv6="inet6 accept_rtadv -no_radr" rtsold_enable="YES" ifconfig_igb1="inet 10.112.146.1/24 fib 1" local_unbound_enable="YES" sshd_enable="YES" ntpd_enable="YES" powerd_enable="YES" gateway_enable="YES" ipv6_gateway_enable="YES" -- Paul. ___ 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"
Getting netgraph stats
I am having a problem monitoring network stats on jails on a host. Scenario: One host, FreeBSD 12.1, with a small number of vnet jails. I'm using netgraph to bridge two or more VLANs from physical NICs into each jail - so each jail has at least 2 ngether interfaces which are the only NICs in the jail. All of this works well. And then I wanted to see what each of my ngethX interface statistics were doing - from my host. snmpd only sees the physical NICs (of course, because the ngeth ones don't appear any more since the jails are started - they all moved to the jails). As another approach, is there any way for me to get the network stats (in/out packets and in/out bytes) from my ngeth netgraph nodes directly? Or have I missed some other way? I really need to monitor the jails from the outside as I cannot guarantee I can reach snmpd running inside the jail (think of the jail as being a private environment where I cannot route my SNMP requests to). Thanks Paul. ___ 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: Netgraph VLANs on Hyper-V
Hi, I have recently been testing with jails, vnet and netgraph on ESXi - so not Hyper-V - but to make this work I needed to: ngctl msg vmx0: setpromisc 1 ngctl msg vmx0: setautosrc 0 outside of the jail when setting up netgraph (where vmx0 is the "real" NIC that the ng_vlans are part of). and then I had to set the mac address for the ngeth interface that was set to be put into the jail ifconfig ngeth0 ether 02:00:01:02:03:04 Once done, and the jail started, ngeth0 worked as expected. In ESXi, the portgroup that vmx0 is connected to allowed spoofing and promiscuous mode. Paul. On 10/04/2020 08:07, Reshad Patuck wrote: Hi, I am trying to use ng_vlan on Hyper-V to deploy vnet jails. The "Enable MAC address Spoofing" setting on the Hyper-V host is enabled. However when I try to use ng_vlan I am not able to reach the jail. If I change this to if_vlan instead everything works fine. Is there something that creating a VLAN using ifconfig does that ng_vlan does not. The same setup works well on VMware ESXi, Xen and KVM. I am not sure if this is relevant to my issue but the hn1 devices sysrc's changes when I use different vlan methods: no vlan: dev.hn.1.rxfilter: 9 dev.hn.1.hwassist: 17 if_vlan: dev.hn.1.rxfilter: 20 dev.hn.1.hwassist: 17 ng_vlan: dev.hn.1.rxfilter: 9 dev.hn.1.hwassist: 0 All the other sysrc's either stay the same or seem to be counters. I can provide you with scripts to setup vlans and jails with both if_vlan and ng_vlan if that helps. Any help understanding what these sysrc's do, or on how I could get ng_vlan to work would be very appreciated. Best, Reshad ___ 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" -- Paul Thornton ___ 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[2]: Re[2]: Network anomalies after update from 11.2 STABLE to 12.1 STABLE
Hi Rick,
RST is only one part of a syndrome. Apart from it, we have a ton of different
other issues. For example: a lot (50+) of ACK and [FIN, ACK] re-transmissions
in cases where they are definitely not needed, as seen in tspdump, unless the
packets that we see in the dump are not actually processed by the kernel(?),
therefore leading to re-transmissions? It definitely has something to do with
races, because issue completely disappears when only single queue is enabled.
In other cases, we have observed that 12.1-STABLE has sent FIN, but then,
when sending the ACK it didn't actually increment SEQ, as if those two packets
FIN an ACK were sent concurrently, though ACK was dispatched later.
Also, I want to focus on a weird behavior, as I wrote in the original post:
issue also disappears if, multiple TCP streams each use different DST port.
It's as if it has anything to do with sharing a port.
19 October 2019, 19:24:43, by "Rick Macklem" :
> Btw, I once ran into a situation where "smart networking" was injecting
> RSTs into a TCP stream. The packet captures at the client and server
> machines were identical, except for the RSTs and the problem went away
> when I connected the two machines with a cable, bypassing the network.
> Might be worth a try, if you can do it?
>
> Good luck with it, rick
>
>
> From: owner-freebsd-...@freebsd.org on behalf
> of Paul
> Sent: Saturday, October 19, 2019 12:09 PM
> To: michael.tue...@lurchi.franken.de; freebsd-net@freebsd.org;
> freebsd-sta...@freebsd.org
> Subject: Re[2]: Network anomalies after update from 11.2 STABLE to 12.1 STABLE
>
> Hi Michael,
>
> Thank you, for taking your time!
>
> We use physical machines. We don not have any special `pf` rules.
> Both sides ran `pfctl -d` before testing.
>
>
> `nginx` config is primitive, no secrets there:
>
> ---
> user www;
> worker_processes auto;
>
> error_log /var/log/nginx/error.log warn;
>
> events {
> worker_connections 81920;
> kqueue_changes 4096;
> use kqueue;
> }
>
> http {
> include mime.types;
> default_typeapplication/octet-stream;
>
> sendfileoff;
> keepalive_timeout 65;
> tcp_nopush on;
> tcp_nodelay on;
>
> # Logging
> log_format main'$remote_addr - $remote_user [$time_local]
> "$request" '
> '$status $request_length $body_bytes_sent
> "$http_referer" '
> '"$http_user_agent" "$http_x_real_ip"
> "$realip_remote_addr" "$request_completion" "$request_time" '
> '"$request_body"';
>
> access_log /var/log/nginx/access.log main;
>
> server {
> listen 80 default;
>
> server_name localhost _;
>
> location / {
> return 404;
> }
> }
> }
> ---
>
>
> `wrk` is compiled with a default configuration. We test like this:
>
> `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency
> http://10.10.10.92:80/missing`
>
>
> Also, it seems that our issue, and the one described in this thread, are
> identical:
>
>https://lists.freebsd.org/pipermail/freebsd-net/2019-June/053667.html
>
> We both have the Intel network cards, BTW. Our network cards are these:
>
> em0 at pci0:10:0:0:class=0x02 card=0x15d9 chip=0x10d38086
> rev=0x00 hdr=0x00
> vendor = 'Intel Corporation'
> device = '82574L Gigabit Network Connection'
>
> ixl0 at pci0:4:0:0:class=0x02 card=0x00078086 chip=0x15728086
> rev=0x01 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Ethernet Controller X710 for 10GbE SFP+'
>
>
> ==
>
> Additional info:
>
> During the tests, we have bonded two interfaces into a lagg:
>
> ixl0: flags=8843 metric 0 mtu 1500
>
> options=c500b8
> ether 3c:fd:fe:aa:60:20
> media: Ethernet autoselect (10Gbase-SR )
> status: active
> nd6 options=29
> ixl1: flags=8843 metric 0 mtu 1500
>
> options=c500b8
> ether 3c:fd:fe:aa:60:20
> hwaddr 3c:fd:fe:aa:60:21
> media: Ethernet autoselect (10Gbase-SR )
> status: active
> nd6 options=29
>
>
> la
Re[2]: Network anomalies after update from 11.2 STABLE to 12.1 STABLE
19 October 2019, 19:35:24, by "Michael Tuexen"
:
> > On 19. Oct 2019, at 18:09, Paul wrote:
> >
> > Hi Michael,
> >
> > Thank you, for taking your time!
> >
> > We use physical machines. We don not have any special `pf` rules.
> > Both sides ran `pfctl -d` before testing.
> Hi Paul,
>
> OK. How are the physical machines connected to each other?
We have tested different connections. The old, copper ethernet, cable,
as well as optics connection with an identical outcome. Machines are
connected through Juniper QFX5100.
>
> What happens when you don't use a lagg interface, but the physical ones?
>
> (Trying to localise the problem...)
Same thing, lagg does not change anything. Originally, the problem was
observed on a regular interface.
We have tested a on different hardware. Results are consistently
stable on 11.2-STABLE and consistently unstable on 12.1-STABLE.
The only unchanged thing is the network card vendor, it's Intel.
>
> Best regards
> Michael
> >
> >
> > `nginx` config is primitive, no secrets there:
> >
> > ---
> > user www;
> > worker_processes auto;
> >
> > error_log /var/log/nginx/error.log warn;
> >
> > events {
> > worker_connections 81920;
> > kqueue_changes 4096;
> > use kqueue;
> > }
> >
> > http {
> > include mime.types;
> > default_typeapplication/octet-stream;
> >
> > sendfileoff;
> > keepalive_timeout 65;
> > tcp_nopush on;
> > tcp_nodelay on;
> >
> > # Logging
> > log_format main'$remote_addr - $remote_user [$time_local]
> > "$request" '
> > '$status $request_length $body_bytes_sent
> > "$http_referer" '
> > '"$http_user_agent" "$http_x_real_ip"
> > "$realip_remote_addr" "$request_completion" "$request_time" '
> > '"$request_body"';
> >
> > access_log /var/log/nginx/access.log main;
> >
> > server {
> > listen 80 default;
> >
> > server_name localhost _;
> >
> > location / {
> > return 404;
> > }
> > }
> > }
> > ---
> >
> >
> > `wrk` is compiled with a default configuration. We test like this:
> >
> > `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency
> > http://10.10.10.92:80/missing`
> >
> >
> > Also, it seems that our issue, and the one described in this thread, are
> > identical:
> >
> >https://lists.freebsd.org/pipermail/freebsd-net/2019-June/053667.html
> >
> > We both have the Intel network cards, BTW. Our network cards are these:
> >
> > em0 at pci0:10:0:0:class=0x02 card=0x15d9 chip=0x10d38086
> > rev=0x00 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = '82574L Gigabit Network Connection'
> >
> > ixl0 at pci0:4:0:0:class=0x02 card=0x00078086 chip=0x15728086
> > rev=0x01 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Ethernet Controller X710 for 10GbE SFP+'
> >
> >
> > ==
> >
> > Additional info:
> >
> > During the tests, we have bonded two interfaces into a lagg:
> >
> > ixl0: flags=8843 metric 0 mtu 1500
> >
> > options=c500b8
> > ether 3c:fd:fe:aa:60:20
> > media: Ethernet autoselect (10Gbase-SR )
> > status: active
> > nd6 options=29
> > ixl1: flags=8843 metric 0 mtu 1500
> >
> > options=c500b8
> > ether 3c:fd:fe:aa:60:20
> > hwaddr 3c:fd:fe:aa:60:21
> > media: Ethernet autoselect (10Gbase-SR )
> > status: active
> > nd6 options=29
> >
> >
> > lagg0: flags=8843 metric 0 mtu 1500
> >
> > options=c500b8
> > ether 3c:fd:fe:aa:60:20
> > inet 10.10.10.92 netmask 0x broadcast 10.10.255.255
> > laggproto failover lagghash l2,l3,l4
> > laggport: ixl0 flags=5
> > laggport: ixl1 flags=0<>
>
Re[2]: Network anomalies after update from 11.2 STABLE to 12.1 STABLE
he other: `ifconfig XXX down` When testing `ixl0` that runs only a single queue: ixl0: Using 1 RX queues 1 TX queues ixl0: netmap queues/slots: TX 1/1024, RX 1/1024 we've got these results: `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.10.92:80/missing` Running 10s test @ http://10.10.10.92:80/missing 1 threads and 10 connections Thread Stats Avg Stdev Max +/- Stdev Latency 281.31us 297.74us 22.66ms 99.70% Req/Sec19.91k 2.79k 21.25k97.59% Latency Distribution 50% 266.00us 75% 309.00us 90% 374.00us 99% 490.00us 164440 requests in 10.02s, 47.52MB read Socket errors: read 0, write 0, timeout 0 Non-2xx or 3xx responses: 164440 Requests/sec: 16412.09 Transfer/sec: 4.74MB When testing `ixl1` that runs 6 queues: ixl1: Using 6 RX queues 6 TX queues ixl1: netmap queues/slots: TX 6/1024, RX 6/1024 we've got these results: `wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency http://10.10.10.92:80/missing` Running 10s test @ http://10.10.10.92:80/missing 1 threads and 10 connections Thread Stats Avg Stdev Max +/- Stdev Latency 216.16us 71.97us 511.00us 47.56% Req/Sec 4.34k 2.76k 15.44k83.17% Latency Distribution 50% 216.00us 75% 276.00us 90% 312.00us 99% 365.00us 43616 requests in 10.10s, 12.60MB read Socket errors: connect 0, read 24, write 8, timeout 0 Non-2xx or 3xx responses: 43616 Requests/sec: 4318.26 Transfer/sec: 1.25MB Do note, that, not only multiple queues cause issues they also dramatically decrease the performance of the network. Using `sysctl -w net.inet.tcp.ts_offset_per_conn=0` didn't help at all. Best regards, -Paul ___ 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"
Network anomalies after update from 11.2 STABLE to 12.1 STABLE
often see errors like these:
Socket errors: connect 12, read 4, write 4, timeout 0
If we reverse the test, by switching two servers places, ie 12.1-STABLE becomes
a client and
issues requests via wrk, we see no problems at all. Same is true between two
between two
11.2-STABLE machines.
It seems like issue appears only when the same local port is used for multiple
connections
on 12.1-STABLE. Currently this is possible only when 12.1-STABLE is a server
and accepts
connections on port, say 80, as in our case. To confirm, this we made another
test. We've
configured nginx to listen on 10 different ports, 80 through 89, and then
launched 10
different wrk processes, each using only one concurrent connection, meaning
that we will
have only 10 TCP streams, each having its own unique port on the 12.1-STABLE's
side:
for I in {0..9}; do wrk -c 1 --header "Connection: close" -d 10 -t 1
--latency http://10.10.10.92:8${I}/missing & ; done
Socket errors stopped appearing. We ran this test many many times, errors just
don't appear.
Though, whenever we repeat a previous test, using a single port:
wrk -c 10 --header "Connection: close" -d 10 -t 1 --latency
http://10.10.10.92:80/missing
errors start appearing again and again:
Socket errors: connect 8, read 14, write 9, timeout 0
We've tested different drivers with the same outcome:
em driver:
em0@pci0:10:0:0:class=0x02 card=0x15d9 chip=0x10d38086 rev=0x00
hdr=0x00
vendor = 'Intel Corporation'
device = '82574L Gigabit Network Connection'
ixl driver:
ixl0@pci0:4:0:0:class=0x02 card=0x00078086 chip=0x15728086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Controller X710 for 10GbE SFP+'
Even the driver from ports (/usr/ports/net/intel-ixl-kmod): ixl-1.11.9
Help with this matter would be really appreciated.
Best regards,
-Paul
___
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[2]: Issues with TCP Timestamps allocation
Thanks for following through and making the patch! Kudos! 17 July 2019, 21:23:33, by "Michael Tuexen" : > > On 17. Jul 2019, at 09:42, Vitalij Satanivskij wrote: > > > > > > > > Hello. > > > > Is there any changes about this problem > Please find a patch in https://reviews.freebsd.org/D20980 > > If possible, please test and report. > > Best regards > Michael > > > > > > I'm using FreeBSD 12 on my desktop and can confirm problem occur with some > > hosts. > > > > > > > > Michael Tuexen wrote: > > MT> > > MT> > > MT> > On 9. Jul 2019, at 14:58, Paul wrote: > > MT> > > > MT> > Hi Michael, > > MT> > > > MT> > 9 July 2019, 15:34:29, by "Michael Tuexen" : > > MT> > > > MT> >> > > MT> >> > > MT> >>> On 8. Jul 2019, at 17:22, Paul wrote: > > MT> >>> > > MT> >>> > > MT> >>> > > MT> >>> 8 July 2019, 17:12:21, by "Michael Tuexen" : > > MT> >>> > > MT> >>>>> On 8. Jul 2019, at 15:24, Paul wrote: > > MT> >>>>> > > MT> >>>>> Hi Michael, > > MT> >>>>> > > MT> >>>>> 8 July 2019, 15:53:15, by "Michael Tuexen" : > > MT> >>>>> > > MT> >>>>>>> On 8. Jul 2019, at 12:37, Paul wrote: > > MT> >>>>>>> > > MT> >>>>>>> Hi team, > > MT> >>>>>>> > > MT> >>>>>>> Recently we had an upgrade to 12 Stable. Immediately after, we > > have started > > MT> >>>>>>> seeing some strange connection establishment timeouts to some > > fixed number > > MT> >>>>>>> of external (world) hosts. The issue was persistent and easy to > > reproduce. > > MT> >>>>>>> Thanks to a patience and dedication of our system engineer we > > have tracked > > MT> >>>>>>> this issue down to a specific commit: > > MT> >>>>>>> > > MT> >>>>>>> https://svnweb.freebsd.org/base?view=revision=338053 > > MT> >>>>>>> > > MT> >>>>>>> This patch was also back-ported into 11 Stable: > > MT> >>>>>>> > > MT> >>>>>>> https://svnweb.freebsd.org/base?view=revision=348435 > > MT> >>>>>>> > > MT> >>>>>>> Among other things this patch changes the timestamp allocation > > strategy, > > MT> >>>>>>> by introducing a deterministic randomness via a hash function > > that takes > > MT> >>>>>>> into account a random key as well as source address, source > > port, dest > > MT> >>>>>>> address and dest port. As the result, timestamp offsets of > > different > > MT> >>>>>>> tuples (SA,SP,DA,DP) will be wildly different and will jump > > from small > > MT> >>>>>>> to large numbers and back, as long as something in the tuple > > changes. > > MT> >>>>>> Hi Paul, > > MT> >>>>>> > > MT> >>>>>> this is correct. > > MT> >>>>>> > > MT> >>>>>> Please note that the same happens with the old method, if two > > hosts with > > MT> >>>>>> different uptimes are bind a consumer grade NAT. > > MT> >>>>> > > MT> >>>>> If NAT does not replace timestamps then yes, it should be the > > case. > > MT> >>>>> > > MT> >>>>>>> > > MT> >>>>>>> After performing various tests of hosts that produce the above > > mentioned > > MT> >>>>>>> issue we came to conclusion that there are some interesting > > implementations > > MT> >>>>>>> that drop SYN packets with timestamps smaller than the largest > > timestamp > > MT> >>>>>>> value from streams of all recent or current connections from a > > specific > > MT> >>>>>>> address. This looks as some kind of SYN flood protection. > > MT> >>>
Re[2]: Issues with TCP Timestamps allocation
Hi Michael,
9 July 2019, 15:34:29, by "Michael Tuexen" :
>
>
> > On 8. Jul 2019, at 17:22, Paul wrote:
> >
> >
> >
> > 8 July 2019, 17:12:21, by "Michael Tuexen" :
> >
> >>> On 8. Jul 2019, at 15:24, Paul wrote:
> >>>
> >>> Hi Michael,
> >>>
> >>> 8 July 2019, 15:53:15, by "Michael Tuexen" :
> >>>
> >>>>> On 8. Jul 2019, at 12:37, Paul wrote:
> >>>>>
> >>>>> Hi team,
> >>>>>
> >>>>> Recently we had an upgrade to 12 Stable. Immediately after, we have
> >>>>> started
> >>>>> seeing some strange connection establishment timeouts to some fixed
> >>>>> number
> >>>>> of external (world) hosts. The issue was persistent and easy to
> >>>>> reproduce.
> >>>>> Thanks to a patience and dedication of our system engineer we have
> >>>>> tracked
> >>>>> this issue down to a specific commit:
> >>>>>
> >>>>> https://svnweb.freebsd.org/base?view=revision=338053
> >>>>>
> >>>>> This patch was also back-ported into 11 Stable:
> >>>>>
> >>>>> https://svnweb.freebsd.org/base?view=revision=348435
> >>>>>
> >>>>> Among other things this patch changes the timestamp allocation strategy,
> >>>>> by introducing a deterministic randomness via a hash function that takes
> >>>>> into account a random key as well as source address, source port, dest
> >>>>> address and dest port. As the result, timestamp offsets of different
> >>>>> tuples (SA,SP,DA,DP) will be wildly different and will jump from small
> >>>>> to large numbers and back, as long as something in the tuple changes.
> >>>> Hi Paul,
> >>>>
> >>>> this is correct.
> >>>>
> >>>> Please note that the same happens with the old method, if two hosts with
> >>>> different uptimes are bind a consumer grade NAT.
> >>>
> >>> If NAT does not replace timestamps then yes, it should be the case.
> >>>
> >>>>>
> >>>>> After performing various tests of hosts that produce the above
> >>>>> mentioned
> >>>>> issue we came to conclusion that there are some interesting
> >>>>> implementations
> >>>>> that drop SYN packets with timestamps smaller than the largest
> >>>>> timestamp
> >>>>> value from streams of all recent or current connections from a specific
> >>>>> address. This looks as some kind of SYN flood protection.
> >>>> This also breaks multiple hosts with different uptimes behind a consumer
> >>>> level NAT talking to such a server.
> >>>>>
> >>>>> To ensure that each external host is not going to see a wild jumps of
> >>>>> timestamp values I propose a patch that removes ports from the equation
> >>>>> all together, when calculating the timestamp offset:
> >>>>>
> >>>>> Index: sys/netinet/tcp_subr.c
> >>>>> ===
> >>>>> --- sys/netinet/tcp_subr.c (revision 348435)
> >>>>> +++ sys/netinet/tcp_subr.c (working copy)
> >>>>> @@ -2224,7 +2224,22 @@
> >>>>> uint32_t
> >>>>> tcp_new_ts_offset(struct in_conninfo *inc)
> >>>>> {
> >>>>> - return (tcp_keyed_hash(inc, V_ts_offset_secret));
> >>>>> +/*
> >>>>> + * Some implementations show a strange behaviour when a wildly
> >>>>> random
> >>>>> + * timestamps allocated for different streams. It seems that
> >>>>> only the
> >>>>> + * SYN packets are affected. Observed implementations drop SYN
> >>>>> packets
> >>>>> + * with timestamps smaller than the largest timestamp value of
> >>>>> all
> >>>>> + * recent or current connections from specific a address. To
> >>>>> mitigate
> >>>>> + * this we are going to ensure that each host will always
> >>>>> observe
> &g
Re[2]: Issues with TCP Timestamps allocation
8 July 2019, 17:12:21, by "Michael Tuexen" :
> > On 8. Jul 2019, at 15:24, Paul wrote:
> >
> > Hi Michael,
> >
> > 8 July 2019, 15:53:15, by "Michael Tuexen" :
> >
> >>> On 8. Jul 2019, at 12:37, Paul wrote:
> >>>
> >>> Hi team,
> >>>
> >>> Recently we had an upgrade to 12 Stable. Immediately after, we have
> >>> started
> >>> seeing some strange connection establishment timeouts to some fixed number
> >>> of external (world) hosts. The issue was persistent and easy to reproduce.
> >>> Thanks to a patience and dedication of our system engineer we have
> >>> tracked
> >>> this issue down to a specific commit:
> >>>
> >>> https://svnweb.freebsd.org/base?view=revision=338053
> >>>
> >>> This patch was also back-ported into 11 Stable:
> >>>
> >>> https://svnweb.freebsd.org/base?view=revision=348435
> >>>
> >>> Among other things this patch changes the timestamp allocation strategy,
> >>> by introducing a deterministic randomness via a hash function that takes
> >>> into account a random key as well as source address, source port, dest
> >>> address and dest port. As the result, timestamp offsets of different
> >>> tuples (SA,SP,DA,DP) will be wildly different and will jump from small
> >>> to large numbers and back, as long as something in the tuple changes.
> >> Hi Paul,
> >>
> >> this is correct.
> >>
> >> Please note that the same happens with the old method, if two hosts with
> >> different uptimes are bind a consumer grade NAT.
> >
> > If NAT does not replace timestamps then yes, it should be the case.
> >
> >>>
> >>> After performing various tests of hosts that produce the above mentioned
> >>> issue we came to conclusion that there are some interesting
> >>> implementations
> >>> that drop SYN packets with timestamps smaller than the largest timestamp
> >>> value from streams of all recent or current connections from a specific
> >>> address. This looks as some kind of SYN flood protection.
> >> This also breaks multiple hosts with different uptimes behind a consumer
> >> level NAT talking to such a server.
> >>>
> >>> To ensure that each external host is not going to see a wild jumps of
> >>> timestamp values I propose a patch that removes ports from the equation
> >>> all together, when calculating the timestamp offset:
> >>>
> >>> Index: sys/netinet/tcp_subr.c
> >>> ===
> >>> --- sys/netinet/tcp_subr.c(revision 348435)
> >>> +++ sys/netinet/tcp_subr.c(working copy)
> >>> @@ -2224,7 +2224,22 @@
> >>> uint32_t
> >>> tcp_new_ts_offset(struct in_conninfo *inc)
> >>> {
> >>> - return (tcp_keyed_hash(inc, V_ts_offset_secret));
> >>> +/*
> >>> + * Some implementations show a strange behaviour when a wildly
> >>> random
> >>> + * timestamps allocated for different streams. It seems that
> >>> only the
> >>> + * SYN packets are affected. Observed implementations drop SYN
> >>> packets
> >>> + * with timestamps smaller than the largest timestamp value of
> >>> all
> >>> + * recent or current connections from specific a address. To
> >>> mitigate
> >>> + * this we are going to ensure that each host will always
> >>> observe
> >>> + * timestamps as increasing no matter the stream: by dropping
> >>> ports
> >>> + * from the equation.
> >>> + */
> >>> +struct in_conninfo inc_copy = *inc;
> >>> +
> >>> +inc_copy.inc_fport = 0;
> >>> +inc_copy.inc_lport = 0;
> >>> +
> >>> + return (tcp_keyed_hash(_copy, V_ts_offset_secret));
> >>> }
> >>>
> >>> /*
> >>>
> >>> In any case, the solution of the uptime leak, implemented in rev338053 is
> >>> not going to suffer, because a supposed attacker is currently able to use
> >>> any fixed values of SP and DP, albeit not 0, anyway, to remove them out
> >>> of the equation.
> >> Can you describe how
Re[2]: Issues with TCP Timestamps allocation
Hi Michael,
8 July 2019, 15:53:15, by "Michael Tuexen" :
> > On 8. Jul 2019, at 12:37, Paul wrote:
> >
> > Hi team,
> >
> > Recently we had an upgrade to 12 Stable. Immediately after, we have started
> > seeing some strange connection establishment timeouts to some fixed number
> > of external (world) hosts. The issue was persistent and easy to reproduce.
> > Thanks to a patience and dedication of our system engineer we have tracked
> > this issue down to a specific commit:
> >
> > https://svnweb.freebsd.org/base?view=revision=338053
> >
> > This patch was also back-ported into 11 Stable:
> >
> > https://svnweb.freebsd.org/base?view=revision=348435
> >
> > Among other things this patch changes the timestamp allocation strategy,
> > by introducing a deterministic randomness via a hash function that takes
> > into account a random key as well as source address, source port, dest
> > address and dest port. As the result, timestamp offsets of different
> > tuples (SA,SP,DA,DP) will be wildly different and will jump from small
> > to large numbers and back, as long as something in the tuple changes.
> Hi Paul,
>
> this is correct.
>
> Please note that the same happens with the old method, if two hosts with
> different uptimes are bind a consumer grade NAT.
If NAT does not replace timestamps then yes, it should be the case.
> >
> > After performing various tests of hosts that produce the above mentioned
> > issue we came to conclusion that there are some interesting implementations
> > that drop SYN packets with timestamps smaller than the largest timestamp
> > value from streams of all recent or current connections from a specific
> > address. This looks as some kind of SYN flood protection.
> This also breaks multiple hosts with different uptimes behind a consumer
> level NAT talking to such a server.
> >
> > To ensure that each external host is not going to see a wild jumps of
> > timestamp values I propose a patch that removes ports from the equation
> > all together, when calculating the timestamp offset:
> >
> > Index: sys/netinet/tcp_subr.c
> > ===
> > --- sys/netinet/tcp_subr.c (revision 348435)
> > +++ sys/netinet/tcp_subr.c (working copy)
> > @@ -2224,7 +2224,22 @@
> > uint32_t
> > tcp_new_ts_offset(struct in_conninfo *inc)
> > {
> > - return (tcp_keyed_hash(inc, V_ts_offset_secret));
> > +/*
> > + * Some implementations show a strange behaviour when a wildly
> > random
> > + * timestamps allocated for different streams. It seems that only
> > the
> > + * SYN packets are affected. Observed implementations drop SYN
> > packets
> > + * with timestamps smaller than the largest timestamp value of all
> > + * recent or current connections from specific a address. To
> > mitigate
> > + * this we are going to ensure that each host will always observe
> > + * timestamps as increasing no matter the stream: by dropping ports
> > + * from the equation.
> > + */
> > +struct in_conninfo inc_copy = *inc;
> > +
> > +inc_copy.inc_fport = 0;
> > +inc_copy.inc_lport = 0;
> > +
> > + return (tcp_keyed_hash(_copy, V_ts_offset_secret));
> > }
> >
> > /*
> >
> > In any case, the solution of the uptime leak, implemented in rev338053 is
> > not going to suffer, because a supposed attacker is currently able to use
> > any fixed values of SP and DP, albeit not 0, anyway, to remove them out
> > of the equation.
> Can you describe how a peer can compute the uptime from two observed
> timestamps?
> I don't see how you can do that...
Supposed attacker could run a script that continuously monitors timestamps,
for example via a periodic TCP connection from a fixed local port (eg 12345)
and a fixed local address to the fixed victim's address and port (eg 80).
Whenever large discrepancy is observed, attacker can assume that reboot has
happened (due to V_ts_offset_secret re-generation), hence the received
timestamp is considered an approximate point of reboot from which the uptime
can be calculated, until the next reboot and so on.
> >
> > There is the list of example hosts that we were able to reproduce the
> > issue with:
> >
> > curl -v http://88.99.60.171:80
> > curl -v http://163.172.71.252:80
> > curl -v http://5.9.242.150:80
> > curl -v https://185.134.205.105:443
> > curl -v https://136.243.1.231:4
Issues with TCP Timestamps allocation
Hi team,
Recently we had an upgrade to 12 Stable. Immediately after, we have started
seeing some strange connection establishment timeouts to some fixed number
of external (world) hosts. The issue was persistent and easy to reproduce.
Thanks to a patience and dedication of our system engineer we have tracked
this issue down to a specific commit:
https://svnweb.freebsd.org/base?view=revision=338053
This patch was also back-ported into 11 Stable:
https://svnweb.freebsd.org/base?view=revision=348435
Among other things this patch changes the timestamp allocation strategy,
by introducing a deterministic randomness via a hash function that takes
into account a random key as well as source address, source port, dest
address and dest port. As the result, timestamp offsets of different
tuples (SA,SP,DA,DP) will be wildly different and will jump from small
to large numbers and back, as long as something in the tuple changes.
After performing various tests of hosts that produce the above mentioned
issue we came to conclusion that there are some interesting implementations
that drop SYN packets with timestamps smaller than the largest timestamp
value from streams of all recent or current connections from a specific
address. This looks as some kind of SYN flood protection.
To ensure that each external host is not going to see a wild jumps of
timestamp values I propose a patch that removes ports from the equation
all together, when calculating the timestamp offset:
Index: sys/netinet/tcp_subr.c
===
--- sys/netinet/tcp_subr.c (revision 348435)
+++ sys/netinet/tcp_subr.c (working copy)
@@ -2224,7 +2224,22 @@
uint32_t
tcp_new_ts_offset(struct in_conninfo *inc)
{
- return (tcp_keyed_hash(inc, V_ts_offset_secret));
+/*
+ * Some implementations show a strange behaviour when a wildly random
+ * timestamps allocated for different streams. It seems that only the
+ * SYN packets are affected. Observed implementations drop SYN packets
+ * with timestamps smaller than the largest timestamp value of all
+ * recent or current connections from specific a address. To mitigate
+ * this we are going to ensure that each host will always observe
+ * timestamps as increasing no matter the stream: by dropping ports
+ * from the equation.
+ */
+struct in_conninfo inc_copy = *inc;
+
+inc_copy.inc_fport = 0;
+inc_copy.inc_lport = 0;
+
+ return (tcp_keyed_hash(_copy, V_ts_offset_secret));
}
/*
In any case, the solution of the uptime leak, implemented in rev338053 is
not going to suffer, because a supposed attacker is currently able to use
any fixed values of SP and DP, albeit not 0, anyway, to remove them out
of the equation.
There is the list of example hosts that we were able to reproduce the
issue with:
curl -v http://88.99.60.171:80
curl -v http://163.172.71.252:80
curl -v http://5.9.242.150:80
curl -v https://185.134.205.105:443
curl -v https://136.243.1.231:443
curl -v https://144.76.196.4:443
curl -v http://94.127.191.194:80
To reproduce, call curl repeatedly with a same URL some number of times.
You are going to see some of the requests stuck in
`*Trying XXX.XXX.XXX.XXX...`
For some reason, the easiest way to reproduce the issue is with nc:
$ echo "foo" | nc -v 88.99.60.171 80
Only a few such calls are required until one of them is stuck on connect():
issuing SYN packets with an exponential backoff.
___
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"
Request for more intelligent local port allocation algorithm
Hi dev team, It's not a secret that when application is trying to establish new TCP connection, without first binding a socket to specific local interface address, OS handles that automatically. Unfortunately there is a catch, that lies in a different logic of local port allocation: (1) when socket is bound before connect() vs (2) when it is not. When allocating the port in in_pcb_lport() by checking whether different ports are free, using in_pcblookup_local(), the behaviour is following: (1) Bound, ie laddr is assigned with specific address: Port is considered occupied only if there is a PCBs that matches both laddr and lport (2) Not bound, ie laddr == INADDR_ANY: Port is considered occupied if there is any PCBs that only matches lport. What this means is that in order to allocate a port none of the all available local addresses should have it allocated, even though this requirement is ridiculous, since we are allocating only one PCB Looking though the code, it seems that (2) is due to the fact that tcp_connect() first allocates the port, indirectly through the call to in_pcbbind() and only then allocates the actual local address, also indirectly, though the call to in_pcbconnect_setup(), that in turn calls in_pcbladdr(). So, probably, in order to guarantee that in_pcbconnect_setup() will not fail we make sure that all range of local addresses are available, no matter which one of them is actually selected by in_pcbladdr()? In real world, this creates serious problems for servers that have a lot of outgoing connections, for example nginx proxy with a lot of open HTTP2 connections. In order to avoid this limitation we have created workarounds within the nginx config as well as within our own software, basically by having 50 local addresses and only following the scenario (1). Alas, all of the built-in Unix utilities as well as other software always follow scenario (2). As the result given large number of connections there may be points in time, when whole range of ports is occupied by at least one local address. Even worse is the outcome of such condition: when in_pcb_lport() travels over the range of possible port numbers, making myriad of calls to in_pcblookup_local(), some kind of important lock is being held withing the kernel. So important that it leads to a complete lock of the system. Even the direct terminal access is not available: it is not responsive. The more calls to connect through scenario (2) there are the longer it takes the system to unfreeze. Given some circumstances, the only option is hard reset. Is it possible to somehow update the code that does connect via scenario (2) to enable more intelligent port allocation, like for example allocating local address and port simultaneously ___ 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"
bridge interface vs. altq
I recently upgraded a system from FreeBSD 9.2 to 12.1-BETA1 and found that pf on the new system complained that my bridge interface did not support ALTQ (worked fine on 9.2) The new kernel is built with OPtions ALTQ options ALTQ_CBQ options ALTQ_CODEL options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options ALTQ_FAIRQ options ALTQ_NOPCC and it seems to have no issues configuring altq on "re" and "dc" interfaces. I searched but could not find any mention of removal of altq support from "bridge," and in fact the current handbook seems to indicate it is supported [www.freebsd.org/doc/handbook/network-bridging.html]: Note: Packet filtering can be used with any firewall package that hooks into the pfil(9) framework. The bridge can be used as a traffic shaper with altq(4) or dummynet(4). What am I missing? thanks! -- G. Paul Ziemba FreeBSD unix: 7:46PM up 4:50, 9 users, load averages: 0.52, 0.41, 0.32 ___ 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"
Avaya
Hi, Are you looking to target companies using Avaya? We provide contacts based in any target vertical and across globe. I have mentioned the information fields that you will receive in the list for each contact within the company. You can also select the industry you would like to target. Information Fields: Name, Title, Email, Phone, Company Name, Physical Address, City, State, Zip Code, Country, Web Address, Employee Size, Revenue Size and Industry. Industry: Healthcare, Telecom, manufacturing, Oil & Gas, Pharmacy, Software, Retail, Real Estate, Construction, Energy, Government, Banking, Legal, Transportation, Wholesale, Agriculture, Business Service, Marketing, Education, Hospitality And Media Internet. Let me know if you are interested and I will get back to you with the counts, sample and pricing. Await for your response. Regards, Paul Kelly Data Consultant To opt out, please reply with Leave Out in the Subject Line. ___ 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: Infor Partner Info
Hi, I was researching your company website and I understand that your company is a "Infor Partner" and I figured it'd be worth leaving a note, We maintain about 25 Million+ B2B contacts from various industries. We are specialized in working with companies whose target market is Infor Users. By helping them acquire relevant Marketing Lists. Just wanted to check if you would be interested in reaching out to Infor users and similar service provider and users with contact information for your Lead Generation, Email campaign, Tele marketing and other marketing initiatives? We have Infor Products Users like: 2DDesignAutomation, 3DDesignAutomation, ACmanagerCRM, Adage, AdvancedPlanning, AdvancedScheduling, AnaelFMS, AnaelHCM, Approva, Baan5.x, BaanIV, Infor BI, BIApplicationStudio, BIDashboards, BIDeltaMiner, BIImportMaster, BIOfficePlus, BPCS, CAS, CloudSuite, Infor COM, Infor CORS, CPM, Infor CRM, Infor DemandPlanning, Infor DistributionFACTS, Infor DistributionSX.e, ESeriesFMS, ESeriesHCM, Infor EAM, Infor e-Commerce, Elevon, EnRoute, EPAK, Epiphany, EzLite, EzPLUS, EzRMS, F9, FourthShift, GlobalHR, GrowthPower, Infor HMS, InfiniumFMS, InfiniumHCM, InfiniumMM/PR, Infopoint, Inforce, Infor ION, Infor KBM, Landmark, Lawson, Leanware, Infor LN, Infor LoadPlanning, Infor LX, MSeriesFMS, MSeriesHCM, Infor M3, M3EAM, MAC-PACXE, MANMAN, MasterpieceFMS, MasterpieceHCM, MAX+TM, MAXCIM, MaxRecall, MediSuite, Ming.le, Infor MK, Mongoose, Infor MP2, NetworkDesign, Optiva, Pathway, PLMDiscrete, PLMFashion, Point.Man, PRISM, InforPRMS, Protean, PublicSector, Infor RFID, RoutePlanning, SalesPortal, SmartStreameXFM, SmartStreamFMS, SmartStreamHCM, StarlightPMS, System21, TRANS4M, Workspace, Infor XA, Infor XBRL, Infor Xpert and many more Users across the globe. All contacts come with the following information: LinkedIn Profile, Company Name, Contact name, Title, Address, Phone, Fax, City, State, Zip codes, Country, Industry, Employee size, Revenue size, Sic Code, Website and verified email address. Unlike any other vendors out there, our lists are dual verified (Email & Call). We only provide you opt in contacts (permission based). Note: If this is not relevant to you please reply back with your Target Market, we have all types of target market available. If it sounds good for you, Please let me know your Exact: Target Industry/Technology User: _ (Any Industry) Target Geography :( worldwide) Target Job Title :__( Any Job Title) So, that I can get back to you with more information like counts, cost and as well as free sample file for your review. Waiting for your Swift Response Regards, Paul Christopher Marketing Manager Cordell Data Marketing Inc. 984 Rowley Drive San Jose 95132 United States To opt out please response Remove in subject line. ___ 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: How can I send packets to 255.255.255.255 from the command line?
On 18/08/2016 21:55, Ryan Stone wrote: On Thu, Aug 18, 2016 at 4:48 PM, Paul A. Procacci <pproca...@datapipe.com> wrote: You should be able to ping the local subnet. Alternatively you can use net/arping. ~Paul I'm specifically looking to test the handling of 255.255.255.255, so a local broadcast address is out. Unfortunately, arping doesn't seem to do the right thing on FreeBSD. It manages to get the kernel to try arp'ing for 255.255.255.255. This very likely comes under the heading of "horrible bodges" but when I needed to do this, after much experimenting I added a static route to 255.255.255.0/24 pointing to the local LAN broadcast address. For example, on a machine with address 192.168.10.10/24 the "fix" would be: route add 255.255.255.0/24 192.168.10.255 My code could then happily send UDP to 255.255.255.255 without issue, and the packets make it out onto the wire with a broadcast destination MAC address. This was under 10.1-RELEASE; things may have changed that make it no longer work. I did warn you that it came under the heading of "horrible bodges" :) Paul. ___ 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: Same NIC name to MAC mapping on FreeBSD
On my production systems, I've never seen it deviate without hardware changes. Are you seeing otherwise? On 6/29/2015 午後 04:23, Wei Hu wrote: Hi, On a FreeBSD system with multiple NICs, ie, multiple MAC addresses, is there a way to keep the same network interface name to MAC address mapping across reboot? It seems on Linux udev rule can help achieve this. Anything similar on FreeBSD? Thanks, Wei ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Frequent hickups on the networking layer
Hi, On 28/04/2015 22:06, Rick Macklem wrote: ... If your net device driver is one that allocates 9K jumbo mbufs for receive instead of using a list of smaller mbuf clusters, I'd guess this is what is biting you. Apologies for the thread drift, but is there a list anywhere of what drivers might have this issue? I've certainly seen performance decrease in the past between two machines with igb interfaces when the MTU was raised to use 9k frames. Paul. ___ 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: net.inet.ip.forwarding is mysteriously set to 0
Hi On 27/04/2015 06:41, Julian Elischer wrote: Basically all the setup scripts in /etc/rc.d (andaother setup scripts in /etc and /usr/local/etc) all source /etc/rc.conf and it's friends (defaults etc.) if any of thse scripts gets called (for example by devd when it notices a new interface), then the entire chain of dependencies related to that chain will be run **according to how the config files tell it to run* * and not how the current sysctls are set. if you think about it, this must be the case as htey need to change the sysctls as part of their operation. maybe we should have a script to do what you want and also uses sysrc(8) to make it permanent. I don't think this is a major problem to be honest. The issue I had back in January is that the behaviour changed with an upgrade to 10.1 from 8.something as the interaction with devd wasn't well known. I don't know how this can be dealt with unless we have a load of special-cases that log warnings when, for example, forwarding is enabled in sysctl.conf but there isn't a gateway_enable in rc.conf. That sounds like a messy solution to be honest. Paul. ___ 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: net.inet.ip.forwarding is mysteriously set to 0
Hi This happens when any interface is created if you've enabled forwarding with the sysctl and not using gateway_enable in rc.conf. It is easily fixed though. See this thread from January: https://docs.freebsd.org/cgi/getmsg.cgi?fetch=403720+0+archive/2015/freebsd-net/20150104.freebsd-net Paul. On 24/04/2015 17:47, Paul S. wrote: Can confirm that anything to do with netif restart on a forwarding interface also creates the same problem. On 4/25/2015 午前 01:46, Nikos Vassiliadis wrote: Hi, Just saw this. Can somebody re-produce this? root@m4fh2:~ # sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 1 root@m4fh2:~ # ifconfig bridge0 create root@m4fh2:~ # sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 0 That's on GENERIC 10-STABLE from the day before yesterday. Thanks, Nikos ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ 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: net.inet.ip.forwarding is mysteriously set to 0
Can confirm that anything to do with netif restart on a forwarding interface also creates the same problem. On 4/25/2015 午前 01:46, Nikos Vassiliadis wrote: Hi, Just saw this. Can somebody re-produce this? root@m4fh2:~ # sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 1 root@m4fh2:~ # ifconfig bridge0 create root@m4fh2:~ # sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 0 That's on GENERIC 10-STABLE from the day before yesterday. Thanks, Nikos ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ng_netgraph and BGP
Additionally, pmacct doesn't seem to really work in FreeBSD -- as far as the latest versions go. Their use of 'return' (with no args) on functions that are meant to return an int flat out makes it unable to compile on FreeBSD. If you fix those by hand, it compiles, but just seems to segfault -- I didn't get the time to look into it further with GDB. There's another option that claims to be able to do the same thing (introduce BGP accounting data to normal flows - ntop's nprobe (www.ntop.org/products/nprobe/), but it's not free. I don't know if it works in FreeBSD well either.) As to the ng_netflow hook, +1, excellent idea. On 4/2/2015 午前 03:08, Nikolay Denev wrote: On Wed, Apr 1, 2015 at 12:50 PM, William Waites wwai...@tardis.ed.ac.uk wrote: I run a small network composed of even smaller networks each encapsulated in an autonomous system. I'd like to do traffic accounting using netflow aggregated by ASN. My border routers run FreeBSD and BIRD. Right now, and this is mentioned in ng_netflow(4), we do not fill in the source and destination ASN because there is no information to get this from the routing daemon's RIB. Probably if we come up with such a way it should be generic so it could be used by Quagga, BIRD or OpenBGPD. I've done a little bit of thinking about how this could be done, and come up with two main strategies: 1. A new kind of netgraph node inserted before ng_netflow knows how to query the routing daemon and decorates the packet with the result, which ng_netflow then puts into the flow packet if present. This entails either a copy (tee) or putting the lookup in the data path which may be suboptimal. 2. A new hook added to the ng_netflow node that allows it to query the routing daemon through a different new kind of netgraph node. This is probably better but may be slightly more complicated to implement. Is anyone working on this or has given this though? I wasn't able to find much by searching the list archives. It may be that I will soon have some students that I can set on this task but would not like to unnecessarily duplicate effort. Cheers, -w -- William Waites wwai...@tardis.ed.ac.uk | School of Informatics http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh http://www.hubs.net.uk/| HUBS AS60241 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Hi, It's not ng_netflow, but if you need this today you can take a look at http://www.pmacct.net ? (there is a package/port too). It comes with BGP daemon (stripped down quagga) and can export this data. --Nikolay ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Unremovable ARP entry and 'address already in use'
Guess was right on the money, thank you! It turns out that there was a route for that entire /23 on another interface for some unfathomable reason. I had to turn that iface down too to remove it, but once I did so, everything is once again peachy! Thank you! On 3/20/2015 午前 12:58, Eric van Gyzen wrote: On 3/19/2015 午前 11:20, Paul S. wrote: root@ipfw-0:~ # arp -d 110.62..211.87 arp: writing to routing socket: Invalid argument I have a vague memory of similar behavior when I had a misconfigured route. I think there was a route for a local interface address with an off-box gateway. (Don't ask. Long story. Not my fault! :) ) Eric ___ 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: Unremovable ARP entry and 'address already in use'
I just noticed that when obfuscating the IP, I added two dots. Please excuse them, the IP is proper (110.62.211.87 for the purposes of this thread) On 3/19/2015 午前 11:20, Paul S. wrote: Hi, Seeing this on 10.1-release p5. FreeBSD ipfw-0.syd.fqdn.tld 10.1-RELEASE-p5 FreeBSD 10.1-RELEASE-p5 #0 r278455: Mon Feb 9 07:18:21 UTC 2015 r...@ipfw-0.syd.fqdn.tld:/usr/obj/usr/src/sys/qfkern amd64 Basically, I have a static arp entry that I cannot remove. This in itself is not a problem. Problem is, when trying to assign that IP address to the same interface, it says the 'address is in use' (which it is not) ? (110.62..211.87) at 00:12:c0:88:03:8f on ix1 permanent [ethernet] Attempting to remove the entry produces an invalid argument error. root@ipfw-0:~ # arp -d 110.62..211.87 arp: writing to routing socket: Invalid argument ix1 does not have this IP configured anymore either. ix1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 description: FW Upstream 0 options=8400bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO ether 00:12:c0:88:03:8f inet6 fe80::212:c0ff:fe88:38f%ix1 prefixlen 64 scopeid 0x2 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (10Gbase-LR full-duplex) status: active When I try to assign it back to ix1, I get this root@ipfw-0:~ # ifconfig ix1 inet 110.62..211.87 netmask 255.255.254.0 ifconfig: ioctl (SIOCAIFADDR): Address already in use I've verified with the provider that there isn't an arp entry at present for this IP address, so the issue seems local to freebsd. Anyone ever see anything like this? I'm aware rebooting will fix it, but this is a live firewall and I'd rather not do that. ___ 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
Unremovable ARP entry and 'address already in use'
Hi, Seeing this on 10.1-release p5. FreeBSD ipfw-0.syd.fqdn.tld 10.1-RELEASE-p5 FreeBSD 10.1-RELEASE-p5 #0 r278455: Mon Feb 9 07:18:21 UTC 2015 r...@ipfw-0.syd.fqdn.tld:/usr/obj/usr/src/sys/qfkern amd64 Basically, I have a static arp entry that I cannot remove. This in itself is not a problem. Problem is, when trying to assign that IP address to the same interface, it says the 'address is in use' (which it is not) ? (110.62..211.87) at 00:12:c0:88:03:8f on ix1 permanent [ethernet] Attempting to remove the entry produces an invalid argument error. root@ipfw-0:~ # arp -d 110.62..211.87 arp: writing to routing socket: Invalid argument ix1 does not have this IP configured anymore either. ix1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 description: FW Upstream 0 options=8400bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO ether 00:12:c0:88:03:8f inet6 fe80::212:c0ff:fe88:38f%ix1 prefixlen 64 scopeid 0x2 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (10Gbase-LR full-duplex) status: active When I try to assign it back to ix1, I get this root@ipfw-0:~ # ifconfig ix1 inet 110.62..211.87 netmask 255.255.254.0 ifconfig: ioctl (SIOCAIFADDR): Address already in use I've verified with the provider that there isn't an arp entry at present for this IP address, so the issue seems local to freebsd. Anyone ever see anything like this? I'm aware rebooting will fix it, but this is a live firewall and I'd rather not do that. ___ 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: FreeBSD responding with wrong receiving interface IP
Joe, That was it, thank you! I looked over net.inet.ip and ip6, icmp never crossed my mind. George, thank you as well. On 3/10/2015 午後 11:40, Joe Holden wrote: On 10/03/2015 13:16, George Neville-Neil wrote: On 10 Mar 2015, at 11:26, Paul S. wrote: Hi, I've been deploying FreeBSD as customer edge routers for customers with sites that do not require high throughput (1g/s). Each site has two ISPs (Mostly Telstra + Verizon/Optus), and take full routes via OpenBGPd and BIRD. I use next-hop self on all received routes. The FreeBSD boxes have static routes delegating the announced IP blocks to a L3 switch down the road. i.e: route add -net 10.100.1.0/24 10.0.0.1, and then that /24 is originated via BGP to both upstreams. Things in general work fine, but I've been receiving reports of 'weird traceroute results' from my customers. Examples of this would be, 1 some.random.isp (...) (...) 2 gigabitethernet3-3.exi1.melbourne.telstra.net (203.50.77.49) 0.309 ms 0.284 ms 0.227 ms 3 bundle-ether3-100.exi-core10.melbourne.telstra.net (203.50.80.1) 1.966 ms 1.675 ms 1.852 ms 4 bundle-ether12.chw-core10.sydney.telstra.net (203.50.11.124) 16.707 ms 15.917 ms 16.360 ms 5 customer-gw.syd.ALTER.net (...) (...) This traceroute seems to claim that the packet was received over the Verizon gateway, which in reality it was not -- it was received directly over the Telstra interface, but my outbound AS-PATH towards some.random.isp uses Verizon. So FreeBSD replies back with the Verizon address. Another person having the same issue (mostly, but on OpenBSD) can be found at http://openbsd.7691.n7.nabble.com/BGP-responding-with-wrong-IP-address-td90264.html I would love to know if there's a way to fix this, or if I've missed something, or if there's something wrong in the way I set it up. Thank you for taking the time to read. I wonder if we could see some routing tables? That might help. Best, George sysctl net.inet.icmp.reply_from_interface=1 will probably do what you expect. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
FreeBSD responding with wrong receiving interface IP
Hi, I've been deploying FreeBSD as customer edge routers for customers with sites that do not require high throughput (1g/s). Each site has two ISPs (Mostly Telstra + Verizon/Optus), and take full routes via OpenBGPd and BIRD. I use next-hop self on all received routes. The FreeBSD boxes have static routes delegating the announced IP blocks to a L3 switch down the road. i.e: route add -net 10.100.1.0/24 10.0.0.1, and then that /24 is originated via BGP to both upstreams. Things in general work fine, but I've been receiving reports of 'weird traceroute results' from my customers. Examples of this would be, 1 some.random.isp (...) (...) 2 gigabitethernet3-3.exi1.melbourne.telstra.net (203.50.77.49) 0.309 ms 0.284 ms 0.227 ms 3 bundle-ether3-100.exi-core10.melbourne.telstra.net (203.50.80.1) 1.966 ms 1.675 ms 1.852 ms 4 bundle-ether12.chw-core10.sydney.telstra.net (203.50.11.124) 16.707 ms 15.917 ms 16.360 ms 5 customer-gw.syd.ALTER.net (...) (...) This traceroute seems to claim that the packet was received over the Verizon gateway, which in reality it was not -- it was received directly over the Telstra interface, but my outbound AS-PATH towards some.random.isp uses Verizon. So FreeBSD replies back with the Verizon address. Another person having the same issue (mostly, but on OpenBSD) can be found at http://openbsd.7691.n7.nabble.com/BGP-responding-with-wrong-IP-address-td90264.html I would love to know if there's a way to fix this, or if I've missed something, or if there's something wrong in the way I set it up. Thank you for taking the time to read. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ifconfig greX create disables IPv6 forwarding
On 09/02/2015 16:34, Daniel Corbe wrote: For some reason, every time I create a GRE interface on a FreeBSD IPv6 gateway, net.inet6.ip6.forwarding is disabled. As long as I manually re-enable it with sysctl, both the GRE tunnel and the IPv6 network behind this machine will continue to work; however, it's certainly far from ideal. I stumbled acro I discovered this in January. See this thread: http://lists.freebsd.org/pipermail/freebsd-net/2015-January/040797.html Are you enabling forwarding using ipv6_gateway_enable in rc.conf, or are you just setting net.inet6.ip6.forwarding to 1 in sysctl.conf? devd gets involved running /etc/rc.d/netif start and that seems to check (and set) the forwarding sysctls based on the rc.conf entries - so if you've set them manually they get reset when a new interface is brought up. Adding ipv6_gateway_enable=YES in /etc/rc.conf should fix this. Paul. ___ 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: Issue with forwarding when creates new interface [was USB Tethering and forwarding]
Hi, I can also replicate this behaviour on 10.1-RELEASE by simply creating an additional vlan interface. It affects IPv4 and IPv6 forwarding. This is taken from a test setup of FreeBSD boxes running Quagga as BGP routers - but with a default GENERIC kernel. This machine has 2x ixgbe, 4x igb and 2x bce physical interfaces, with a cloned lo1 and vlan0. [root@test1 ~]# uname -a FreeBSD test1.prtsystems.ltd.uk 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 [root@test1 ~]# sysctl -a | grep forwarding net.inet.ip.forwarding: 1 net.inet.ip.fastforwarding: 1 net.inet6.ip6.forwarding: 1 [root@test1 ~]# ifconfig vlan1 create [root@test1 ~]# sysctl -a | grep forwarding net.inet.ip.forwarding: 0 net.inet.ip.fastforwarding: 1 net.inet6.ip6.forwarding: 0 I haven't tried using 10.0 as a router, so don't know if this crept in between 10.0 and 10.1 or 9 and 10. Paul. On 03/01/2015 13:12, wishmaster wrote: Hi, I have been seeing strange behavior of my system lately. After creating new interface the system variable net.inet.ip.forwarding becomes 0. E.g. manually load if_ral kernel module, then rel0 interface appears and net.inet.ip.forwarding becomes 0. Previously this happened when I attached smartphone with USB tethering is on. May be this is VIMAGE-related... Any ideas? Below my original first post. Hi, list. Server works as router for small network and some services in the jails. When I connect Android-based smartphone and attempt to use USB Tethering, the net.inet.ip.forwarding becomes 0 and I must change it to 1 every time. Is this normal behavior? FreeBSD server.local 10.1-STABLE FreeBSD 10.1-STABLE #1 r275636: Mon Dec 22 11:05:33 EET 2014 wishmaster@server.local:/usr/obj/usr/src/sys/SMS i386 Kernel has been compiled with VIMAGE Cheers, Vitaliy ___ 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: Issue with forwarding when creates new interface [was USB Tethering and forwarding]
Hi, On 03/01/2015 18:06, Mike Tancsa wrote: do you set forwarding via just /etc/sysctl.conf or in /etc/rc.conf via ipv6_gateway_enable and gateway_enable. I seem to recall some discussion about there being a difference. Perhaps devd is calling something that then fiddles with the setting ignoring whats in sysctl.conf ? That seems to be what is happening. In the earlier post, I was just setting the three sysctls in /etc/sysctl.conf - and observed that forwarding went away if an interface was added. Doing it by setting fastforwarding only in sysctl.conf, and setting both gateway_enables to yes in rc.conf fixes the problem: [root@test1 ~]# sysctl -a | grep forwarding net.inet.ip.forwarding: 1 net.inet.ip.fastforwarding: 1 net.inet6.ip6.forwarding: 1 [root@test1 ~]# ifconfig vlan1 create [root@test1 ~]# sysctl -a | grep forwarding net.inet.ip.forwarding: 1 net.inet.ip.fastforwarding: 1 net.inet6.ip6.forwarding: 1 That's quite ... odd, to sat the least. I can't see anything in devd.conf which would relate to a new interface being created, but that doesn't mean that there isn't some magic functionality in there. Paul. ___ 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
IP fast forwarding and setkey
Hi folks, I plan to make an edge router out of a freebsd system with OpenBGPD + FreeBSD 10, or such. I've been reading up, and noticed that the net.inet.ip.fastforwarding flag provides rather nice performance benefits. My issue is, my upstream networks insist on using TCP MD5 authentication on their BGP sessions. This is fine, except on FreeBSD -- I'm going to have to use the setkey utility to set those since native PF_KEY support for OpenBGPD does not seem available. Now, since setkey is part of IPSec, and there are countless warnings about using IPSec and fastforwarding together in the manpage, am I correct in assuming that this will not work if I have fastforwarding enabled? Is there any way to make it work? Quagga, from what I've read, seems to also be in the same boat (Usage of setkey required for TCP MD5). I tried searching the manpages, but couldn't locate anything concrete on this. Any assistance/replies are welcome. Thank you! ___ 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: IP fast forwarding and setkey
Ermal, I'd prefer a raw BSD installation (Call it a comfort thing, if you will). Has the pfSense project actually managed to patch OpenBGPD to remove its dependency on OpenBSD specific bindings for TCP_MD5? It might be worth it to just try to build their fork, if that's the case. Thank you for responding! On 9/21/2014 午後 07:26, Ermal Luçi wrote: If for you is an option pfSense has all the hard work done for you and you can use it for such installations. On Sun, Sep 21, 2014 at 12:08 PM, Paul S. cont...@winterei.se mailto:cont...@winterei.se wrote: Hi folks, I plan to make an edge router out of a freebsd system with OpenBGPD + FreeBSD 10, or such. I've been reading up, and noticed that the net.inet.ip.fastforwarding flag provides rather nice performance benefits. My issue is, my upstream networks insist on using TCP MD5 authentication on their BGP sessions. This is fine, except on FreeBSD -- I'm going to have to use the setkey utility to set those since native PF_KEY support for OpenBGPD does not seem available. Now, since setkey is part of IPSec, and there are countless warnings about using IPSec and fastforwarding together in the manpage, am I correct in assuming that this will not work if I have fastforwarding enabled? Is there any way to make it work? Quagga, from what I've read, seems to also be in the same boat (Usage of setkey required for TCP MD5). I tried searching the manpages, but couldn't locate anything concrete on this. Any assistance/replies are welcome. Thank you! ___ freebsd-net@freebsd.org mailto: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 mailto:freebsd-net-unsubscr...@freebsd.org -- Ermal ___ 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: IP fast forwarding and setkey
Interesting. Would you happen to know where I could obtain sources to their version of OpenBGPD, then? Thanks! On 9/21/2014 午後 07:35, Ermal Luçi wrote: On Sun, Sep 21, 2014 at 12:31 PM, Paul S. cont...@winterei.se mailto:cont...@winterei.se wrote: Ermal, I'd prefer a raw BSD installation (Call it a comfort thing, if you will). Has the pfSense project actually managed to patch OpenBGPD to remove its dependency on OpenBSD specific bindings for TCP_MD5? It might be worth it to just try to build their fork, if that's the case. Thank you for responding! Yeah OpenBGPd port of pfSense has the support for installing SPDs without setkey. On 9/21/2014 午後 07:26, Ermal Luçi wrote: If for you is an option pfSense has all the hard work done for you and you can use it for such installations. On Sun, Sep 21, 2014 at 12:08 PM, Paul S. cont...@winterei.se mailto:cont...@winterei.se wrote: Hi folks, I plan to make an edge router out of a freebsd system with OpenBGPD + FreeBSD 10, or such. I've been reading up, and noticed that the net.inet.ip.fastforwarding flag provides rather nice performance benefits. My issue is, my upstream networks insist on using TCP MD5 authentication on their BGP sessions. This is fine, except on FreeBSD -- I'm going to have to use the setkey utility to set those since native PF_KEY support for OpenBGPD does not seem available. Now, since setkey is part of IPSec, and there are countless warnings about using IPSec and fastforwarding together in the manpage, am I correct in assuming that this will not work if I have fastforwarding enabled? Is there any way to make it work? Quagga, from what I've read, seems to also be in the same boat (Usage of setkey required for TCP MD5). I tried searching the manpages, but couldn't locate anything concrete on this. Any assistance/replies are welcome. Thank you! ___ freebsd-net@freebsd.org mailto: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 mailto:freebsd-net-unsubscr...@freebsd.org -- Ermal -- Ermal ___ 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
[Solved] Re: IP fast forwarding and setkey
So, just to notify -- I got a copy of the pfsense port of OpenBGPD (available from the pfsense-tools repository -- see https://forum.pfsense.org/index.php?topic=76132.0) and TCP-MD5 indeed does work in the build. Configuring local-address per peer is mandatory, however. I think it uses that to configure the SPDs. Cheers! On 9/21/2014 午後 07:35, Ermal Luçi wrote: On Sun, Sep 21, 2014 at 12:31 PM, Paul S. cont...@winterei.se mailto:cont...@winterei.se wrote: Ermal, I'd prefer a raw BSD installation (Call it a comfort thing, if you will). Has the pfSense project actually managed to patch OpenBGPD to remove its dependency on OpenBSD specific bindings for TCP_MD5? It might be worth it to just try to build their fork, if that's the case. Thank you for responding! Yeah OpenBGPd port of pfSense has the support for installing SPDs without setkey. On 9/21/2014 午後 07:26, Ermal Luçi wrote: If for you is an option pfSense has all the hard work done for you and you can use it for such installations. On Sun, Sep 21, 2014 at 12:08 PM, Paul S. cont...@winterei.se mailto:cont...@winterei.se wrote: Hi folks, I plan to make an edge router out of a freebsd system with OpenBGPD + FreeBSD 10, or such. I've been reading up, and noticed that the net.inet.ip.fastforwarding flag provides rather nice performance benefits. My issue is, my upstream networks insist on using TCP MD5 authentication on their BGP sessions. This is fine, except on FreeBSD -- I'm going to have to use the setkey utility to set those since native PF_KEY support for OpenBGPD does not seem available. Now, since setkey is part of IPSec, and there are countless warnings about using IPSec and fastforwarding together in the manpage, am I correct in assuming that this will not work if I have fastforwarding enabled? Is there any way to make it work? Quagga, from what I've read, seems to also be in the same boat (Usage of setkey required for TCP MD5). I tried searching the manpages, but couldn't locate anything concrete on this. Any assistance/replies are welcome. Thank you! ___ freebsd-net@freebsd.org mailto: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 mailto:freebsd-net-unsubscr...@freebsd.org -- Ermal -- Ermal ___ 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
problems with ifconfig alias via rc.conf
Hello, Today I ran into a little problem with ifconfig and rc scripts. I have tried googling this issue, although all I could find, are people pointing at syntax errors. Perhaps someone here has ran into this before and could provide some pointers. Here is the relevant /etc/rc.conf settings; defaultrouter=94.247.171.193 ifconfig_igb0=up ifconfig_igb1=up ifconfig_igb2=up ifconfig_igb3=up cloned_interfaces=lagg0 lagg1 ifconfig_lagg0=laggproto failover laggport igb0 laggport igb1 94.247.171.197/32 netmask 255.255.255.240 broadcast 94.247.171.207 #ifconfig_lagg0_alias0=inet 94.247.171.195 netmask 255.255.255.255 ifconfig_lagg1=laggproto failover laggport igb2 laggport igb3 10.0.0.53/32 netmask 255.255.255.0 #ifconfig_lagg1_alias0=inet 10.0.0.150 netmask 255.255.255.255 static_routes=vpn route_vpn=-net 10.0.8.0/22 10.0.0.1 In short, - we have four real igb network cards. - they are paired into lagg0, lagg1 fail-over mode. - each lagg interface has an alias which by default is disabled. - static route for vpn traffic. Today we were doing some maintenance and wanted to enable the aliases. So after removing the commented out lines from rc.conf, we ran; ~# service netif restart ~# service routing restart ~# service pf restart Output from `ifconfig` showed the aliases where listening on their respective interfaces. However, ping/telnet on 94.247.171.195 failed. At some point we decided to manually cycle the alias; ~# ifconfig lagg0 -alias 94.247.171.195 netmask 255.255.255.255 ~# ifconfig lagg0 alias 94.247.171.195 netmask 255.255.255.255 Which then worked. Output from `ifconfig` was just like before. Some info; - we are running FreeBSD 9.2-RELEASE-p10. - in dmesg we had ifa_del_loopback_route: deletion failed. - interestingly enough, the other 10.0.0.150 alias worked just fine. Perhaps something is mis-configured in /etc/rc.conf? Some argument is missing in ifconfig_* variables ? Thanks in advance, Jean Paul ___ 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: problems with ifconfig alias via rc.conf
On 07/16/2014 12:52 PM, Maciej Milewski wrote: Double mask definition? You are trying to define 94.247.171.197 with mask 32 and then with mask 28. Remove the /32 from this line and use simple 94.247.171.197 netmask 255.255.255.240 broadcast 94.247.171.207 Alias is defined correctly. The same as above. Better use 10.0.0.53/24 or 10.0.0.53 netmask 255.255.255.0 I can't believe it was such a stupid mistake from my end :-) I guess you could say I had a syntax error ;-) Sorry for the trouble, and thank you for your time! Jean Paul ___ 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: DNAT in freebsd
On Sat, Jun 29, 2013 at 09:50:15AM +0300, Sami Halabi wrote:
I think I was misunderstood...
Here is the situation i want to handle:
My box is a router that handles several /24 behind.
One of my links (em0) is connected to a private network 192.168.0.1 is me,
my neighbour is 192.168.0.2.
I want to make that any connection comes to 192.168.0.1 to go to ip
193.xxx.yyy.2 using specific public ip 84.xx.yy.1
And packets comming to my public 84.xx.yy.1 ip to be trsnslated as came
from 192.168.0.1 and sent to 192.168.0.2/or ant other ips
behind(192.168.1.xx/24).
Hope that makes it clearer, and I appreciate any help.
Sami
29 2013 03:30, ?? Paul A. Procacci
pproca...@datapipe.com:
The answer I provided you does exactly what you want it to do. Not to mention
the man page goes over other things as well if the answer I provided you
wasn't accurate. Here is my config that I use for my home setup.
The config:
- binds a nat instance on the primary interface
- denies all inbound syn's among other things
- Forward packets originating on the internal network interface through nat
- and returns packets (ack's) back to the original sender.
!!
#!/bin/sh
## Start of IPFW Configuration
# Set rules command prefix :: Rule numbering cannot exceed 900
cmd=/sbin/ipfw -q
pif=de0 # Public NIC
iif=bridge0 # Internal NIC
##
# Flush current rules and do config.
$cmd -f flush
$cmd enable one_pass
##
${cmd} add 1 allow all from any to any via lo0
${cmd} add 2 deny all from any to 127.0.0.0/8
${cmd} add 3 deny ip from 127.0.0.0/8 to any
${cmd} nat 1 config if ${pif} log deny_in reset unreg_only same_ports
${cmd} add 00020 nat 1 all from any to any via ${pif}
${cmd} add 00050 allow all from any to any via ${iif}
${cmd} add 65534 deny log all from any to any
!!
Again, this information is found in `man ipfw(8)` and does what you are
asking.
~Paul
This message may contain confidential or privileged information. If you are not
the intended recipient, please advise us immediately and delete this message.
See http://www.datapipe.com/legal/email_disclaimer/ for further information on
confidentiality and the risks of non-secure electronic communication. If you
cannot access these links, please notify us by reply message and we will send
the contents to you.
___
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: DNAT in freebsd
Hi, (sorry for sending again, the last email was with wrong subject) I would like to perform a full dnat/snat as in iptbles in: linux-ip.net/html/nat-dnat.html How it can be done in fbsd, I use ipfw. I seeked natd man page but its translation, and thr proxy_rule is for specefic port, not a whole transparancy. Using in-kernel nat is probably a better choice IMHO. read `man ipfw(8)` The section labeled EXAMPLES has exactly what you need. Here is a snippet from the manpage to get you started: --- !--snip-- Then to configure nat instance 123 to alias all the outgoing traffic with ip 192.168.0.123, blocking all incoming connections, trying to keep same ports on both sides, clearing aliasing table on address change and keep- ing a log of traffic/link statistics: ipfw nat 123 config ip 192.168.0.123 log deny_in reset same_ports !--snip-- ipfw nat 123 config redirect_addr 10.0.0.1 10.0.0.66 redirect_port tcp 192.168.0.1:80 500 redirect_proto udp 192.168.1.43 192.168.1.1 redirect_addr 192.168.0.10,192.168.0.11 10.0.0.100 # LSNAT redirect_port tcp 192.168.0.1:80,192.168.0.10:22 500# LSNAT !--snip-- --- ~Paul This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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: IPFW tablearg questions
The question: Why can't you add a skipto to the default rule (65535)? http://lists.freebsd.org/pipermail/freebsd-ipfw/2007-June/003067.html I also consider using tablearg with divert, but manpage is contradicting itself in regards to divert with tablearg: divert port Divert packets that match this rule to the divert(4) socket bound to port port. The search terminates. vs The tablearg argument can be used with the following actions: nat, pipe, queue, divert, tee, netgraph, ngtee, fwd, skipto, setfib, action parameters: tag, untag, rule options: limit, tagged. Also, in the EXAMPLES section one can find: In the following example per-interface firewall is created: ipfw table 10 add vlan20 12000 ipfw table 10 add vlan30 13000 ipfw table 20 add vlan20 22000 ipfw table 20 add vlan30 23000 .. ipfw add 100 ipfw skipto tablearg ip from any to any recv 'table(10)' in ipfw add 200 ipfw skipto tablearg ip from any to any xmit 'table(10)' out where ipfw add 100 ipfw skipto seems wrong... I'm not sure where the contradiction is. Have you tried something like the following as an example? I'm not sure the below works, but in my mind it does. ;) # ipfw table 10 add 129.168.0.0/24 1234 ipfw table 10 add 10.5.21.0/24 5678 ipfw add 100 divert tablearg ip from table(10) to any # Perhaps knowing what it is you are trying to accomplish would lead to a more concrete answer. ~Paul This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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: Is it possible to slow down the network interface?
On Tue, Apr 02, 2013 at 04:25:58PM -0700, Yuri wrote: For the testing purposes, I would like to be able to control the maximum speed of the interface. ipfw (pf too?) can artifically control speeds via dummynet. There are man pages describing all of the above and should be a good starting place for you. ~Paul This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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: mbuf tuning on 9.1
How can I increase mbufs, as they appear above, and mbuf clusters, as they appear above? You can modify the sysctl's associated with mbufs to suit your needs. https://wiki.freebsd.org/NetworkPerformanceTuning The following link describes what mbufs are and sysctl's governing their operation. ~Paul This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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: Cas driver fails to load first time after boot.
On 01/25/13 17:34, Marius Strobl wrote: On Fri, Jan 25, 2013 at 01:14:51PM -0600, Paul Keusemann wrote: On 01/25/13 10:19, Marius Strobl wrote: On Thu, Jan 24, 2013 at 08:48:04PM -0600, Paul Keusemann wrote: On 01/24/13 15:50, Marius Strobl wrote: On Thu, Jan 24, 2013 at 12:39:44PM -0600, Paul Keusemann wrote: On 01/24/13 09:09, Marius Strobl wrote: On Tue, Jan 22, 2013 at 02:46:48PM -0600, Paul Keusemann wrote: Hi, I've got a Dell R200 which I'm trying to build into a gateway with a Sun QGE (501-6738-10). The cas driver fails to load the first time I try to load it but succeeds the second time. Is this a problem with the card, the driver, my karma? Wrong phase of the moon, apparently :) The MII setup of these chips is a bit tricky and I'm not sure whether I've hit all code paths during development of the driver. I certainly didn't test with a 501-6738, these have been reported as working before, though. It also doesn't make much sense that attaching the devices succeeds on the second attempt. Could you please use a if_cas.ko built with the attached patch and report the debug output for one of the interfaces in both the working and the non-working case? I would love to give you output from the working and non-working case but apparently the phase of the moon has changed, I can't get it to fail now. The messages output from the working case is attached. Thanks but unfortunately this doesn't make any sense either. In general, printf()s cause deays which can be relevant. In the locations I've put them they hardly can make such a difference though. If you haven't already done so, could you please power off the machine before doing the test with the patched module? Is the problem still gone if you revert to the original module? OK, power-cycling makes a difference. The driver fails to attach all of the devices after power-cycling most of the time if not all of the time. The number of devices attached varies, the attached message file fragment is from my last test. Three of the devices were attached on the first load attempt and all four of them on the second attempt. Okay, so we now at least have a way to reproduce the problem. Unfortunately, it's still unclear what's the exact cause of it. At least the problem is not what I suspected and hoped it most likely is. Could you please test how things behave after a power-cycle with the attached patche (after reverting the previous one). The patched driver fails to compile with the following error message: ... I found the following defintion of nitems in the iwn and usb/wlan drivers: #define nitems(_a) (sizeof((_a)) / sizeof((_a)[0])) so I added it to if_cas.c and rebuilt without errors. Sorry, I didn't think of 8.3 not having nitems(), yet. Actually, this part of the patch is orthogonal to your problem and just a change I had in that tree. This looks like like it fixed the problem. I ran three tests from power-up to loading the driver and the driver loaded successfully all three times. I then added if_cas_load=YES to /boot/loader.conf and did two more successful reboots from power-up. Great! Thanks a lot for testing! Will this driver work on FreeBSD 9.1? Yes, the patch should also solve the problem in 9.1. I suspect the hang you are seeing there isn't specific to cas(4) but rather a general regression that came in with the VIMAGE changes. Now, if a network device driver fails to attach during boot and tries to clean up by detaching and freeing the interface part at that stage again this causes problems. I already talked to bz@ about this and what I remember from his reply this is an ordering issue that is at least very hard to fix. OK. I've successfully upgraded from 8.3-Release to 9.1-Release. I stupidly powered-down the machine after the upgrade, so I had to remove the QGE card to get it to boot 9.1 and build a custom kernel. The patch applied cleanly, the kernel built without errors and boots from power-up without problems. I've attached the most recent messages file, dmesg, kldstat and ifconfig output if you're interested. The only odd thing I noticed was that cas0 and cas3 log messages: cannot disable RX MAC but cas1 and cas2 do not. I haven't actually tried any of the interfaces yet but I assume they'll work as expected. Let me know if there's anything further testing you'd like me to do. Thanks so much for your help with this, it is much appreciated. Paul Marius -- Paul Keusemannpkeu...@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378 Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-RELEASE #4: Mon Jan 28 09:02:45 CST 2013 toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 CPU: Intel(R
Re: Cas driver fails to load first time after boot.
On 01/24/13 09:09, Marius Strobl wrote: On Tue, Jan 22, 2013 at 02:46:48PM -0600, Paul Keusemann wrote: Hi, I've got a Dell R200 which I'm trying to build into a gateway with a Sun QGE (501-6738-10). The cas driver fails to load the first time I try to load it but succeeds the second time. Is this a problem with the card, the driver, my karma? Wrong phase of the moon, apparently :) The MII setup of these chips is a bit tricky and I'm not sure whether I've hit all code paths during development of the driver. I certainly didn't test with a 501-6738, these have been reported as working before, though. It also doesn't make much sense that attaching the devices succeeds on the second attempt. Could you please use a if_cas.ko built with the attached patch and report the debug output for one of the interfaces in both the working and the non-working case? I would love to give you output from the working and non-working case but apparently the phase of the moon has changed, I can't get it to fail now. The messages output from the working case is attached. Let me know if there's anything else I can do. Marius -- Paul Keusemannpkeu...@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378 Jan 24 11:00:01 lucid newsyslog[2087]: logfile turned over due to size100K Jan 24 11:47:39 lucid shutdown: reboot by toor: Jan 24 11:47:41 lucid syslogd: exiting on signal 15 Jan 24 11:48:51 lucid syslogd: kernel boot file is /boot/kernel/kernel Jan 24 11:48:51 lucid kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jan 24 11:48:51 lucid kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 24 11:48:51 lucid kernel: The Regents of the University of California. All rights reserved. Jan 24 11:48:51 lucid kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 24 11:48:51 lucid kernel: FreeBSD 8.3-RELEASE #0: Thu Jan 24 11:15:13 CST 2013 Jan 24 11:48:51 lucid kernel: toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 Jan 24 11:48:51 lucid kernel: Timecounter i8254 frequency 1193182 Hz quality 0 Jan 24 11:48:51 lucid kernel: CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Jan 24 11:48:51 lucid kernel: Origin = GenuineIntel Id = 0x6fb Family = 6 Model = f Stepping = 11 Jan 24 11:48:51 lucid kernel: Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Jan 24 11:48:51 lucid kernel: Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM Jan 24 11:48:51 lucid kernel: AMD Features=0x20100800SYSCALL,NX,LM Jan 24 11:48:51 lucid kernel: AMD Features2=0x1LAHF Jan 24 11:48:51 lucid kernel: TSC: P-state invariant Jan 24 11:48:51 lucid kernel: real memory = 4294967296 (4096 MB) Jan 24 11:48:51 lucid kernel: avail memory = 4099231744 (3909 MB) Jan 24 11:48:51 lucid kernel: ACPI APIC Table: DELL PE_SC3 Jan 24 11:48:51 lucid kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Jan 24 11:48:51 lucid kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) Jan 24 11:48:51 lucid kernel: cpu0 (BSP): APIC ID: 0 Jan 24 11:48:51 lucid kernel: cpu1 (AP): APIC ID: 1 Jan 24 11:48:51 lucid kernel: cpu2 (AP): APIC ID: 2 Jan 24 11:48:51 lucid kernel: cpu3 (AP): APIC ID: 3 Jan 24 11:48:51 lucid kernel: ioapic0: Changing APIC ID to 4 Jan 24 11:48:51 lucid kernel: ioapic1: Changing APIC ID to 5 Jan 24 11:48:51 lucid kernel: ioapic0 Version 2.0 irqs 0-23 on motherboard Jan 24 11:48:51 lucid kernel: ioapic1 Version 2.0 irqs 32-55 on motherboard Jan 24 11:48:51 lucid kernel: kbd1 at kbdmux0 Jan 24 11:48:51 lucid kernel: acpi0: DELL PE_SC3 on motherboard Jan 24 11:48:51 lucid kernel: acpi0: [ITHREAD] Jan 24 11:48:51 lucid kernel: acpi0: Power Button (fixed) Jan 24 11:48:51 lucid kernel: Timecounter ACPI-fast frequency 3579545 Hz quality 1000 Jan 24 11:48:51 lucid kernel: acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 Jan 24 11:48:51 lucid kernel: cpu0: ACPI CPU on acpi0 Jan 24 11:48:51 lucid kernel: cpu1: ACPI CPU on acpi0 Jan 24 11:48:51 lucid kernel: cpu2: ACPI CPU on acpi0 Jan 24 11:48:51 lucid kernel: cpu3: ACPI CPU on acpi0 Jan 24 11:48:51 lucid kernel: pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 Jan 24 11:48:51 lucid kernel: pci0: ACPI PCI bus on pcib0 Jan 24 11:48:51 lucid kernel: pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 Jan 24 11:48:51 lucid kernel: pci1: ACPI PCI bus on pcib1 Jan 24 11:48:51 lucid kernel: pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 Jan 24 11:48:51 lucid kernel: pci2: ACPI PCI bus on pcib2 Jan 24 11:48:51 lucid kernel: pcib3: ACPI PCI-PCI bridge at device 0.0 on pci2 Jan 24 11:48:51 lucid kernel: pci3: ACPI PCI bus on pcib3 Jan 24 11:48:51 lucid kernel: pcib4: PCI-PCI bridge at device 2.0 on pci3 Jan 24 11:48:51 lucid kernel: pci4: PCI bus on pcib4 Jan 24 11:48:51 lucid kernel: pci4
Re: Cas driver fails to load first time after boot.
On 01/24/13 15:50, Marius Strobl wrote: On Thu, Jan 24, 2013 at 12:39:44PM -0600, Paul Keusemann wrote: On 01/24/13 09:09, Marius Strobl wrote: On Tue, Jan 22, 2013 at 02:46:48PM -0600, Paul Keusemann wrote: Hi, I've got a Dell R200 which I'm trying to build into a gateway with a Sun QGE (501-6738-10). The cas driver fails to load the first time I try to load it but succeeds the second time. Is this a problem with the card, the driver, my karma? Wrong phase of the moon, apparently :) The MII setup of these chips is a bit tricky and I'm not sure whether I've hit all code paths during development of the driver. I certainly didn't test with a 501-6738, these have been reported as working before, though. It also doesn't make much sense that attaching the devices succeeds on the second attempt. Could you please use a if_cas.ko built with the attached patch and report the debug output for one of the interfaces in both the working and the non-working case? I would love to give you output from the working and non-working case but apparently the phase of the moon has changed, I can't get it to fail now. The messages output from the working case is attached. Thanks but unfortunately this doesn't make any sense either. In general, printf()s cause deays which can be relevant. In the locations I've put them they hardly can make such a difference though. If you haven't already done so, could you please power off the machine before doing the test with the patched module? Is the problem still gone if you revert to the original module? OK, power-cycling makes a difference. The driver fails to attach all of the devices after power-cycling most of the time if not all of the time. The number of devices attached varies, the attached message file fragment is from my last test. Three of the devices were attached on the first load attempt and all four of them on the second attempt. In the interest of full disclosure, I did build a new kernel but it is just a copy of GENERIC. This is a Marius -- Paul Keusemannpkeu...@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378 Jan 24 20:32:32 lucid kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jan 24 20:32:32 lucid kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 24 20:32:32 lucid kernel: The Regents of the University of California. All rights reserved. Jan 24 20:32:32 lucid kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 24 20:32:32 lucid kernel: FreeBSD 8.3-RELEASE #0: Thu Jan 24 11:15:13 CST 2013 Jan 24 20:32:32 lucid kernel: toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 Jan 24 20:32:32 lucid kernel: Timecounter i8254 frequency 1193182 Hz quality 0 Jan 24 20:32:32 lucid kernel: CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Jan 24 20:32:32 lucid kernel: Origin = GenuineIntel Id = 0x6fb Family = 6 Model = f Stepping = 11 Jan 24 20:32:32 lucid kernel: Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Jan 24 20:32:32 lucid kernel: Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM Jan 24 20:32:32 lucid kernel: AMD Features=0x20100800SYSCALL,NX,LM Jan 24 20:32:32 lucid kernel: AMD Features2=0x1LAHF Jan 24 20:32:32 lucid kernel: TSC: P-state invariant Jan 24 20:32:32 lucid kernel: real memory = 4294967296 (4096 MB) Jan 24 20:32:32 lucid kernel: avail memory = 4099231744 (3909 MB) Jan 24 20:32:32 lucid kernel: ACPI APIC Table: DELL PE_SC3 Jan 24 20:32:32 lucid kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Jan 24 20:32:32 lucid kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) Jan 24 20:32:32 lucid kernel: cpu0 (BSP): APIC ID: 0 Jan 24 20:32:32 lucid kernel: cpu1 (AP): APIC ID: 1 Jan 24 20:32:32 lucid kernel: cpu2 (AP): APIC ID: 2 Jan 24 20:32:32 lucid kernel: cpu3 (AP): APIC ID: 3 Jan 24 20:32:32 lucid kernel: ioapic0: Changing APIC ID to 4 Jan 24 20:32:32 lucid kernel: ioapic1: Changing APIC ID to 5 Jan 24 20:32:32 lucid kernel: ioapic0 Version 2.0 irqs 0-23 on motherboard Jan 24 20:32:32 lucid kernel: ioapic1 Version 2.0 irqs 32-55 on motherboard Jan 24 20:32:32 lucid kernel: kbd1 at kbdmux0 Jan 24 20:32:32 lucid kernel: acpi0: DELL PE_SC3 on motherboard Jan 24 20:32:32 lucid kernel: acpi0: [ITHREAD] Jan 24 20:32:32 lucid kernel: acpi0: Power Button (fixed) Jan 24 20:32:32 lucid kernel: Timecounter ACPI-fast frequency 3579545 Hz quality 1000 Jan 24 20:32:32 lucid kernel: acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 Jan 24 20:32:32 lucid kernel: cpu0: ACPI CPU on acpi0 Jan 24 20:32:32 lucid kernel: cpu1: ACPI CPU on acpi0 Jan 24 20:32:32 lucid kernel: cpu2: ACPI CPU on acpi0 Jan 24 20:32:32 lucid kernel: cpu3: ACPI CPU on acpi0 Jan 24 20:32:32 lucid kernel: pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
Cas driver fails to load first time after boot.
-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master,auto, auto-flow Jan 22 14:04:33 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 22 14:04:33 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 22 14:04:33 lucid kernel: cas3: [FILTER] The following are attached: /var/run/dmesg.boot dmesg output after the second attempt to load the cas driver. /var/log/messages after the second attemp to load the cas driver. -- Paul Keusemannpkeu...@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378 Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.3-RELEASE #0: Mon Apr 9 21:23:18 UTC 2012 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.42-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fb Family = 6 Model = f Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4099231744 (3909 MB) ACPI APIC Table: DELL PE_SC3 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 4 ioapic1: Changing APIC ID to 5 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 32-55 on motherboard kbd1 at kbdmux0 acpi0: DELL PE_SC3 on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 0.0 on pci2 pci3: ACPI PCI bus on pcib3 pcib4: PCI-PCI bridge at device 2.0 on pci3 pci4: PCI bus on pcib4 pci4: network, ethernet at device 0.0 (no driver attached) pci4: network, ethernet at device 1.0 (no driver attached) pci4: network, ethernet at device 2.0 (no driver attached) pci4: network, ethernet at device 3.0 (no driver attached) pcib5: ACPI PCI-PCI bridge irq 16 at device 28.4 on pci0 pci5: ACPI PCI bus on pcib5 bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x004201 mem 0xdf3f-0xdf3f irq 16 at device 0.0 on pci5 bge0: CHIP ID 0x4201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus0: MII bus on bge0 brgphy0: BCM5750 10/100/1000baseTX PHY PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:19:b9:fa:82:51 bge0: [ITHREAD] pcib6: ACPI PCI-PCI bridge irq 17 at device 28.5 on pci0 pci6: ACPI PCI bus on pcib6 bge1: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x004201 mem 0xdf4f-0xdf4f irq 17 at device 0.0 on pci6 bge1: CHIP ID 0x4201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus1: MII bus on bge1 brgphy1: BCM5750 10/100/1000baseTX PHY PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 00:19:b9:fa:82:52 bge1: [ITHREAD] uhci0: Intel 82801I (ICH9) USB controller port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: Intel 82801I (ICH9) USB controller on uhci0 uhci1: Intel 82801I (ICH9) USB controller port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: Intel 82801I (ICH9) USB controller on uhci1 uhci2: Intel 82801I (ICH9) USB controller port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: Intel 82801I (ICH9) USB controller on uhci2 ehci0: Intel 82801I (ICH9) USB 2.0 controller mem 0xdf2ffc00-0xdf2f irq 21 at device 29.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: Intel 82801I (ICH9) USB 2.0 controller on ehci0 pcib7: ACPI PCI-PCI bridge at device 30.0 on pci0 pci7: ACPI PCI bus on pcib7 vgapci0: VGA-compatible display port 0xec00-0xecff mem 0xd000-0xd7ff,0xdf5f-0xdf5f irq 19 at device 5.0 on pci7 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0
Re: one physical interface - n virtual interfaces
On Tue, Oct 16, 2012 at 10:35:55PM +0200, Mariano Cediel wrote: How do I create, from a physical interface, n virtual interfaces, but all effects are real, their MAC different, on which we can do individually NAT, etc, etc.? I need one external interface has 2 public IPs, and I'll do every NAT over every interface (with ipfw and divert) individually (each of them has its own gateway) A little help to start researching . Greetings. http://freebsd.1045724.n5.nabble.com/Virtual-Network-Interface-Card-td4005109.html The above was posted in late 2010. It has one example of creating vitual interfaces using the netgraph module. 3rd post from the top. I'm not entirely sure if this is the current _correct_ way, but I imagine is still accurate and can be used to get you started. ~Paul This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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: DHCP server with a group of mac address
In dhcp.conf it describes ways to assign client's to classes. It further explains how to `deny` or `allow` those clients assigned to those classes. Read the subsection from dhcpd.conf(5) called `SUBCLASSES`. It provides an example which almost answers your question in its entirety. ~Paul On Wed, Sep 26, 2012 at 05:58:11PM +0800, d...@mybsd.org.my wrote: Hi, i'm installing isc-dhcp42-server and run in the network for like 1000 node. i have like 1000 mac address (servers, PC's, printers, phones, etc) which i put in the text file. FYI, Any mac address (which is in the text file) who plug into the network will get the ip address based on the vlan configured on the switch. Any mac address who's NOT in the text file, will not getting any IP and they will not authorize to be in our network. Is this possible to do with isc-dhcp ? I try to search around these topic but not much help. Anyone have any tips / shed me some light ? --- ded1 MyBSD Malaysia Project http://www.MyBSD.org.my ___ 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 This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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: Multiroute question
On Thu, Sep 20, 2012 at 01:25:50PM -0400, Michael MacLeod wrote: Actually, multiple routing tables is the correct solution. I documented it here: http://www.mmacleod.ca/blog/2011/06/source-based-routing-with-freebsd-using-multiple-routing-table/ From the post: ... But route-to and reply-to do not trump the default routing table for traffic that originates or terminates on the router itself. They are useful only for traffic passing through the router. pf can only make routing decisions when a packet passes through an interface. It can try and set the reply-to interface to be the second WAN connection when an inbound SSH connection is made, but neither the SSH daemon nor the routing table on the host know or care about the routing preferences of pf. FWIW, I've many dual-homed machined running perfectly by combining pf for filtering and ipfw for policy-based routing. Basically, ipfw is configured roughly as follows (a.b.c.0/29 is the first WAN connection and d.e.f.0/29 the second): 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 01001 allow carp from any to any 01002 allow pfsync from any to any 01100 allow ip from any to 10.0.0.0/8 01101 allow ip from any to 172.16.0.0/12 01102 allow ip from any to 192.168.0.0/16 01103 allow ip from any to 224.0.0.0/3 01110 allow ip from any to my_internal_public_adressblock_1 0 allow ip from any to my_internal_public_adressblock_2 ... 01200 fwd a.b.c.1 ip from a.b.c.0/29 to any 01201 fwd d.e.f.1 ip from d.e.f.0/29 to any 65535 allow ip from any to any Lines 1100 thru pass all traffic that should not go out over a WAN interface, they follow the normal routing table. I need the lines 011xx because I have multiple public IP address blocks on the inside and behind tunnels. Lines 1200 and 1201 forward packets to either WAN interface depending on the source address. I also have a default gateway set to my preferred WAN interface for connections originating from this host where the client does not explicitly select a source address. This works both for packets being routed and for packets originating from the dual homes host itself. I've been using this since FreeBSD 6 and never felt the need to switch to multiple routing tables because this fits the purpose and is quite clean IMO. It's also not necessary to run multiple server processes (like sshd, sendmail, httpd) for every routing domain. With kind regards, Paul Schenkeveld ___ 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: tcpdump in freebsd
tcpdump -ni interface src host ip tcpdump -ni interface not src host ip ~Paul On Thu, Jul 26, 2012 at 08:35:29AM +, m s wrote: hi all. I want to use tcpdump just for input or just for outout packet.isthis possible ? if no is there any other command that do this? thanks ___ 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 This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP
On Thu, Jul 12, 2012 at 03:25:07PM -0700, Chris Benesch wrote:
Maybe another option to dhclient to have it poll the interface every 2-3
seconds to see if it has lost a link and if so, set the lease timer to be
expired, and wait for it to come back and once it does, it will acquire a
new address.
___
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
The Operating system should generate a devd event.
Something like the following in /usr/local/etc/devd.conf should do the trick,
though I haven't tested the below with anything other than carp interfaces.
I suspect it works just the same.
##
notify 30 {
match system IFNET;
match subsystem em0_or_whatever;
match type LINK_UP;
action /usr/local/sbin/script_to_do_something.sh up;
};
notify 30 {
match system IFNET;
match subsystem em0_or_whatever;
match type LINK_DOWN;
action /usr/local/sbin/script_to_do_something.sh down;
};
##
~Paul
This message may contain confidential or privileged information. If you are not
the intended recipient, please advise us immediately and delete this message.
See http://www.datapipe.com/legal/email_disclaimer/ for further information on
confidentiality and the risks of non-secure electronic communication. If you
cannot access these links, please notify us by reply message and we will send
the contents to you.
___
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: problem on ipfw using mac addresses
Have you set net.link.ether.ipfw? ~Paul On Wed, Jul 04, 2012 at 05:34:04PM +0430, h bagade wrote: Hi all, I have a problem using ipfw firewall. I have a topology connected as below: A(192.168.1.55) - (192.168.1.1)my_sys(192.168.2.1) ---(192.168.2.12)B I've set the rule ipfw add 1 deny icmp from any to any on my_sys, which works correctly. I can't ping from A to B by the rule. Then I've added mac part to the rule as the format of ipfw add 1 deny icmp from any to any ma any any which seems the same as before but after that I could ping the B from A. What's the reason? I'm really confused with what I saw! Is it a bug? Any hints or suggestions are really appreciated. ___ 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 This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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: setting up dns server
- What bind listening? (Can you see it with netstat?)
- What port is it listening to?
- What errors (if any) are in the error log?
I'm afraid your question really isn't a specific FreeBSD problem.
You might have better luck on the BIND mailing list.
~Paul
On Wed, Jul 04, 2012 at 06:43:00AM -0700, m s wrote:
Hi all.
I want to config FreeBSD as a dns server. I did below configuration but
when I use nslookup command it doesn't work. I also enabled named service
in rc.conf file and put my ip as a nameserver in resolv.conf.
what am I missing?is there anything else I should do?
any help would be appriciated.
My named.conf file:
---
options {
directory /etc/namedb;
pid-file /var/run/named/pid;
dump-file/var/dump/named_dump.db;
statistics-file /var/stats/named.stats;
};
zone . { type hint; file /etc/namedb/named.root; };
zone 0.0.127.IN-ADDR.ARPA {
type master;
file master/localhost.rev;
};
zone ictptk.net { type master; file /etc/namedb/master/db.domain; };
zone 10.10.10.in-addr.arpa {
type master;
file /etc/named/master/db.ict;
};
---
my db.ict file :
---
$TTL 3600
@IN SOA ns.ictptk.net. root.ns.ictptk.net. (
2001220200
;Serial
3600
;Refresh
900
;Retry
360
;Expire
3600
)
;Minimum
IN NS ns.ictptk.net.
1 IN PTRictptk.net.
---
my db.domain file :
---
$TTL 3600
@IN SOA ns.ictptk.net. root.ns.ictptk.net. (
2001220200
;Serial
3600
;Refresh
900
;Retry
360
;Expire
3600
)
;Minimum
INNS ns.ictptk.net.
ictptk.net IN A 10.10.10.1
www.ictptk.net. INCNAME ictptk.net.
___
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
This message may contain confidential or privileged information. If you are not
the intended recipient, please advise us immediately and delete this message.
See http://www.datapipe.com/legal/email_disclaimer/ for further information on
confidentiality and the risks of non-secure electronic communication. If you
cannot access these links, please notify us by reply message and we will send
the contents to you.
___
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: fsck problem FreeBSD 8.3
Nothing logged in /var/log/* or crashes that exist in /var/crash would indicate to me some sort of hardware related problem. Have you tested your hardware lately and know that it is in operational order? ~Paul On Mon, Apr 09, 2012 at 09:36:54PM +0300, ??? ??? wrote: Hi. Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY, CANNOT RUN FAST FSCK Apr 9 19:51:58 fsck: Apr 9 19:51:58 fsck: Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Apr 9 19:51:58 fsck: /dev/ad8s1e: CANNOT SET FS_NEEDSFSCK FLAG Apr 9 20:09:22 kernel: running manually: # fsck -y /dev/ad8s1e ** /dev/ad8s1e (NO WRITE) ** Last Mounted on /tmp ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 99 files, 10 used, 506477 free (45 frags, 63304 blocks, 0.0% fragmentation) Server reboot two or three time per day # uname -a FreeBSD flux 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #3 r231881: Fri Feb 24 17:07:48 UTC 2012 adm@flux:/usr/obj/usr/src/sys/KES_KERN_v8 amd64 before this it works about month without problems /var/crash - empty, in /var/log/messages there is no any messages before crash. Can any help to fix problem? ___ 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 This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
if_bridge stops when running virtualbox 4.1.8
Hi, I just noticed that when running Virtualbox 4.1.8 with a bridged network interface, I loose connectivity to another virtual host running in qemu whose network interface is bridged to my ethernet interface. After stopping the Virtualbox instance, I regain connection to the virtual host under qemu. Ifconfig doesn't give a clue. Has anyone seen this behaviour or, even better, have a solution? My host is running 8.2-RELEASE, here's the relevant ifconfig output: em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu +1500 options=2098VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:1f:16:xx:xx:xx inet 10.0.0.10 netmask 0xff00 broadcast 10.0.0.255 nd6 options=3PERFORMNUD,ACCEPT_RTADV media: Ethernet autoselect (1000baseT full-duplex) status: active tap0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu +1500 options=8LINKSTATE ether 00:bd:32:xx:xx:xx nd6 options=3PERFORMNUD,ACCEPT_RTADV Opened by PID 13433 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 8a:55:3f:xx:xx:xx id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 5 priority 128 path cost 200 member: em0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 1 priority 128 path cost 2 vboxnet0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 0a:00:27:00:00:00 Thanks! Paul Schenkeveld ___ 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: must define username in radius client???
Assuming ssh (you didn't specify), you only need to setup the shared secret between machines. The rest is handled by pam/login as normal (ala auth sufficient pam_radius.so) cat /etc/radius.conf auth 10.5.21.4:1645 SuperSkret 3 2 auth 10.5.21.5:1645 SuperSkret 3 2 ~Paul On Tue, Feb 21, 2012 at 11:24:03AM +0330, saeedeh motlagh wrote: hello guys, i wanna have authentication via radius server. in my local network, one system is radius server and the others are clients. the server is running well. when a client login, it sends an access-request to the server. if the user name and password are defined in the server, the server sends back the access-accept to client. if the user name is defined in the client, the login is successful but if this user name is not defined in the client, the login failed and say login incorrect although the client receives access-accept from the server. i wanna know if there is any way to have authentication successfully without defining any user name in the client system? yours, ___ 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 This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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: Help : configuring wpa_suplpicant.conf for WEP + login/passwd
On Wed, Feb 15, 2012 at 04:02:22PM +0100, Arno J. Klaassen wrote: Hello, Paul A. Procacci pproca...@datapipe.com writes: Is your DHCP daemon setup to listen on the interface where the AP is running? Dunno... How could eventually be sure Windows got it's IP-addres by DHCP? Sorry, you hadn't made it very clear if you were attempting to get a lease from a DHCP server running on a FreeBSD machine or not. I assumed you were, and had assumed your configuration may have been wrong. However, given your response, I assume you're using an off the shelf AP. There are several things that come to mind as to why you wouldn't get a DHCP lease, like MAC filtering as an example. You'll have to check the logs of the DHCP server to see if your requests are even making it to the daemon. tcpdump will come in handy if you have shell capabilities on your AP. For username/password prompt upon browser launch, you'll need to configure a reverse proxy to get a cookie upon successful auth to pass through the proxy. Could you please explain me how to do this? As for the proxy, you'll need to look at squid. I've personally never done what you need, but a buddy of mine has using squid. I can't give you any further details as the configuration/administrator of squid I know nothing about. I do know though that it has the capabilities you seek. ~Paul This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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: Help : configuring wpa_suplpicant.conf for WEP + login/passwd
Is your DHCP daemon setup to listen on the interface where the AP is running? For username/password prompt upon browser launch, you'll need to configure a reverse proxy to get a cookie upon successful auth to pass through the proxy. ~Paul On Tue, Feb 14, 2012 at 09:49:01PM -0800, Adrian Chadd wrote: Wep? With a username/password? I've not seen this. Does anyone have any ideas? Adrian On 14 February 2012 05:51, Arno J. Klaassen a...@heho.snv.jussieu.fr wrote: Hello, could someone provide me wit a hint how to get wpa_supplicant to work in the following environment : ?- standard ?: IEEE 802.11 (at least they pretend in the doc) ?- ? ?mode ? : infrastructure (?) ?- ? ?WEP ? ?: 128bit ?- Authent ? : open ?- and then username/password upon browser-launch (at least under ? Windows) When I put the following to wpa_suplicant.conf I get State : ASSOCIATED - COMPLETED ?: ?ssid=their-ID ?(unpublished) ?scan_ssid=1 ?key_mgmt=NONE ?wep_key0=part1 ?wep_key1=part2 ?wep_key2=part3 However, 'dhclient wlan0' says No DHCPOFFERS received Any help appreciated. Thanx in advance, regards, Arno ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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: how to debug non-working hole in nat
add divert natd all from any to any via bridge0 This nat's all internal traffic on your lan. You probably don't want this. I'd place the nat on the tun0 interface. Which leads me to If you machine receives a syn from the tun0 interface, what firewall rule is in place to redirect the packet to the nat instance? I do not see any. ~Paul This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/about-us-legal-email-disclaimer.htm for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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: [PATCH] ndis: safe fpu on amd64
On 11/22/11, Kostik Belousov kostik...@gmail.com wrote: On Mon, Nov 21, 2011 at 03:49:16PM +, Paul B. Mahol wrote: Hi, This patch should fix panic on amd64 when using ndis with drivers which make use of fpu registers. Do not allocate fpu_kern_ctx on stack. Its size is 528 bytes on amd64 right now, and potentially can grow after AVX support is finished. So I need to introduce locks and allocate fpu_kern_ctx per CPU because otherwise memory leaks are possible. ___ 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
[PATCH] ndis: safe fpu on amd64
Hi,
This patch should fix panic on amd64 when using ndis with drivers
which make use of fpu registers.
diff --git a/sys/compat/ndis/kern_windrv.c b/sys/compat/ndis/kern_windrv.c
index 5572988..1a93b54 100644
--- a/sys/compat/ndis/kern_windrv.c
+++ b/sys/compat/ndis/kern_windrv.c
@@ -55,6 +55,9 @@ __FBSDID($FreeBSD$);
#ifdef __i386__
#include machine/segments.h
#endif
+#ifdef __amd64__
+#include machine/fpu.h
+#endif
#include dev/usb/usb.h
@@ -613,6 +616,86 @@ windrv_wrap(func, wrap, argcnt, ftype)
return (0);
}
+
+uint64_t
+_x86_64_call1(void *fn, uint64_t a)
+{
+ struct fpu_kern_ctx fpu_ctx_save;
+ uint64_t ret;
+
+ fpu_kern_enter(curthread, fpu_ctx_save, FPU_KERN_NORMAL);
+ ret = x86_64_call1(fn, a);
+ fpu_kern_leave(curthread, fpu_ctx_save);
+
+ return (ret);
+}
+
+uint64_t
+_x86_64_call2(void *fn, uint64_t a, uint64_t b)
+{
+ struct fpu_kern_ctx fpu_ctx_save;
+ uint64_t ret;
+
+ fpu_kern_enter(curthread, fpu_ctx_save, FPU_KERN_NORMAL);
+ ret = x86_64_call2(fn, a, b);
+ fpu_kern_leave(curthread, fpu_ctx_save);
+
+ return (ret);
+}
+
+uint64_t
+_x86_64_call3(void *fn, uint64_t a, uint64_t b, uint64_t c)
+{
+ struct fpu_kern_ctx fpu_ctx_save;
+ uint64_t ret;
+
+ fpu_kern_enter(curthread, fpu_ctx_save, FPU_KERN_NORMAL);
+ ret = x86_64_call3(fn, a, b, c);
+ fpu_kern_leave(curthread, fpu_ctx_save);
+
+ return (ret);
+}
+
+uint64_t
+_x86_64_call4(void *fn, uint64_t a, uint64_t b, uint64_t c, uint64_t d)
+{
+ struct fpu_kern_ctx fpu_ctx_save;
+ uint64_t ret;
+
+ fpu_kern_enter(curthread, fpu_ctx_save, FPU_KERN_NORMAL);
+ ret = x86_64_call4(fn, a, b, c, d);
+ fpu_kern_leave(curthread, fpu_ctx_save);
+
+ return (ret);
+}
+
+uint64_t
+_x86_64_call5(void *fn, uint64_t a, uint64_t b, uint64_t c, uint64_t d,
+uint64_t e)
+{
+ struct fpu_kern_ctx fpu_ctx_save;
+ uint64_t ret;
+
+ fpu_kern_enter(curthread, fpu_ctx_save, FPU_KERN_NORMAL);
+ ret = x86_64_call5(fn, a, b, c, d, e);
+ fpu_kern_leave(curthread, fpu_ctx_save);
+
+ return (ret);
+}
+
+uint64_t
+_x86_64_call6(void *fn, uint64_t a, uint64_t b, uint64_t c, uint64_t d,
+uint64_t e, uint64_t f)
+{
+ struct fpu_kern_ctx fpu_ctx_save;
+ uint64_t ret;
+
+ fpu_kern_enter(curthread, fpu_ctx_save, FPU_KERN_NORMAL);
+ ret = x86_64_call6(fn, a, b, c, d, e, f);
+ fpu_kern_leave(curthread, fpu_ctx_save);
+
+ return (ret);
+}
#endif /* __amd64__ */
diff --git a/sys/compat/ndis/pe_var.h b/sys/compat/ndis/pe_var.h
index 84e0162..276ad1c 100644
--- a/sys/compat/ndis/pe_var.h
+++ b/sys/compat/ndis/pe_var.h
@@ -460,22 +460,29 @@ extern uint64_t x86_64_call5(void *, uint64_t, uint64_t, uint64_t, uint64_t,
extern uint64_t x86_64_call6(void *, uint64_t, uint64_t, uint64_t, uint64_t,
uint64_t, uint64_t);
-
-#define MSCALL1(fn, a) \
- x86_64_call1((fn), (uint64_t)(a))
-#define MSCALL2(fn, a, b) \
- x86_64_call2((fn), (uint64_t)(a), (uint64_t)(b))
-#define MSCALL3(fn, a, b, c) \
- x86_64_call3((fn), (uint64_t)(a), (uint64_t)(b), \
- (uint64_t)(c))
-#define MSCALL4(fn, a, b, c, d) \
- x86_64_call4((fn), (uint64_t)(a), (uint64_t)(b), \
+uint64_t _x86_64_call1(void *, uint64_t);
+uint64_t _x86_64_call2(void *, uint64_t, uint64_t);
+uint64_t _x86_64_call3(void *, uint64_t, uint64_t, uint64_t);
+uint64_t _x86_64_call4(void *, uint64_t, uint64_t, uint64_t, uint64_t);
+uint64_t _x86_64_call5(void *, uint64_t, uint64_t, uint64_t, uint64_t,
+uint64_t);
+uint64_t _x86_64_call6(void *, uint64_t, uint64_t, uint64_t, uint64_t,
+uint64_t, uint64_t);
+
+#define MSCALL1(fn, a) \
+ _x86_64_call1((fn), (uint64_t)(a))
+#define MSCALL2(fn, a, b) \
+ _x86_64_call2((fn), (uint64_t)(a), (uint64_t)(b))
+#define MSCALL3(fn, a, b, c) \
+ _x86_64_call3((fn), (uint64_t)(a), (uint64_t)(b), (uint64_t)(c))
+#define MSCALL4(fn, a, b, c, d) \
+ _x86_64_call4((fn), (uint64_t)(a), (uint64_t)(b), \
(uint64_t)(c), (uint64_t)(d))
-#define MSCALL5(fn, a, b, c, d, e)\
- x86_64_call5((fn), (uint64_t)(a), (uint64_t)(b), \
+#define MSCALL5(fn, a, b, c, d, e) \
+ _x86_64_call5((fn), (uint64_t)(a), (uint64_t)(b), \
(uint64_t)(c), (uint64_t)(d), (uint64_t)(e))
-#define MSCALL6(fn, a, b, c, d, e, f)\
- x86_64_call6((fn), (uint64_t)(a), (uint64_t)(b), \
+#define MSCALL6(fn, a, b, c, d, e, f) \
+ _x86_64_call6((fn), (uint64_t)(a), (uint64_t)(b), \
(uint64_t)(c), (uint64_t)(d), (uint64_t)(e), (uint64_t)(f))
#endif /* __amd64__ */
___
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
[High Interrupt Count] Networking Difficulties
Gents, I'm having quite an aweful problem that I need a bit of help with. I have an HPDL360 G3 ( http://h18000.www1.hp.com/products/quickspecs/11504_na/11504_na.HTML ) which acts as a NAT (via PF) for several (600+) class C's amongst 24+ machines sitting behind it. It's running FPSense (FreeBSD 8.1-RELEASE-p4). The important guts are: 2 x 2.8 GHz Cpus 2 BGE interfaces on a PCI-X bus. During peak times this machine is only able to handle between 500Mbps - 600Mbps before running out of cpu capacity. (300Mbps(ish) on the LAN, 300Mbps(ish) on the WAN) It's due to the high number of interrupts. I was speaking with a networking engineer here and he mentioned that I should look at Interrupt Coalescing to increase throughput. The only information I found online regarding this was a post from 2 years ago here: http://lists.freebsd.org/pipermail/freebsd-net/2009-June/07.html The tunables mentioned in the above post aren't present in my system, so I imagine this never made it into the bge driver. Assuming this to be the case, I started looking at DEVICE_POLLING as a solution. I did try implementing device polling, but the results were worse than I expected. netisr was using 100% of a single cpu while the other cpu remained mostly idle. Not knowing exactly what netisr is, I reverted the changes. This leads me to this list. Given the scenario above, I'm nearly certain I need to use device polling instead of the standard interrupt driven setup. The two sysctl's that I've come across thus far that I think are what I need are: net.isr.maxthreads hern.hz I would assume setting net.isr.maxthreads to 2 given my dual core machine is advisable, but I'm not 100% sure. What are the caveats in setting this higher? Given the output of `sysctl -d net.isr.maxthreads` I would expect anything higher than the number of cores to be detrimental. Is this correct? kern.hz I'm more unsure of. I understand what the sysctl is, but I'm not sure how to come up with a reasonable number. Generally speaking, and in your experience, would a setting of 2000 achive close to the theoritical meximum of the cards? Is there an upper limit that I would be worried about? Random Question: - is device polling really the answer? I am missing something in the bge driver that I've overlooked? - what tunables directly effect processing high volumes of packets. Network Interfaces: ## bge0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:0b:cd:ca:1d:1a inet 209.18.70.211 netmask 0xff00 broadcast 209.18.70.255 inet6 fe80::20b:cdff:feca:1d1a%bge0 prefixlen 64 scopeid 0x1 nd6 options=3PERFORMNUD,ACCEPT_RTADV media: Ethernet autoselect (1000baseT full-duplex) status: active bge1: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether 00:0b:cd:ca:1a:74 inet 172.16.0.3 netmask 0xfffc broadcast 172.19.255.255 inet6 fe80::20b:cdff:feca:1a74%bge1 prefixlen 64 scopeid 0x2 nd6 options=3PERFORMNUD,ACCEPT_RTADV media: Ethernet autoselect (1000baseT full-duplex) status: active ## I appreciate the help in advance. Thanks, Paul This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/about-us-legal-email-disclaimer.htm for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ 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: [High Interrupt Count] Networking Difficulties
On Mon, Oct 31, 2011 at 08:57:46PM -0500, Paul A. Procacci wrote: Gents, I'm having quite an aweful problem that I need a bit of help with. I have an HPDL360 G3 ( http://h18000.www1.hp.com/products/quickspecs/11504_na/11504_na.HTML ) which acts as a NAT (via PF) for several (600+) class C's amongst 24+ machines sitting behind it. It's running FPSense (FreeBSD 8.1-RELEASE-p4). The important guts are: 2 x 2.8 GHz Cpus 2 BGE interfaces on a PCI-X bus. During peak times this machine is only able to handle between 500Mbps - 600Mbps before running out of cpu capacity. (300Mbps(ish) on the LAN, 300Mbps(ish) on the WAN) It's due to the high number of interrupts. I was speaking with a networking engineer here and he mentioned that I should look at Interrupt Coalescing to increase throughput. The only information I found online regarding this was a post from 2 years ago here: http://lists.freebsd.org/pipermail/freebsd-net/2009-June/07.html The tunables mentioned in the above post aren't present in my system, so I imagine this never made it into the bge driver. Assuming this to be the case, I started looking at DEVICE_POLLING as a solution. I did try implementing device polling, but the results were worse than I expected. netisr was using 100% of a single cpu while the other cpu remained mostly idle. Not knowing exactly what netisr is, I reverted the changes. This leads me to this list. Given the scenario above, I'm nearly certain I need to use device polling instead of the standard interrupt driven setup. The two sysctl's that I've come across thus far that I think are what I need are: net.isr.maxthreads hern.hz I would assume setting net.isr.maxthreads to 2 given my dual core machine is advisable, but I'm not 100% sure. What are the caveats in setting this higher? Given the output of `sysctl -d net.isr.maxthreads` I would expect anything higher than the number of cores to be detrimental. Is this correct? kern.hz I'm more unsure of. I understand what the sysctl is, but I'm not sure how to come up with a reasonable number. Generally speaking, and in your experience, would a setting of 2000 achive close to the theoritical meximum of the cards? Is there an upper limit that I would be worried about? Random Question: - is device polling really the answer? I am missing something in the bge driver that I've overlooked? - what tunables directly effect processing high volumes of packets. snip After some more coffee, and source code reading, I've now learned that having device polling enabled forces netisr to limit the number of threads it creates to 1. This kinda defeats the purpose of enabling device polling. This makes me believe that device polling isn't going to be a great solution afterall. A snippet from dmesg: snip bge0: Compaq NC7781 Gigabit Server Adapter, ASIC rev. 0x001002 mem 0xf7ef-0xf7ef irq 30 at device 2.0 on pci1 brgphy0: BCM5703 10/100/1000baseTX PHY PHY 1 on miibus0 bge1: Compaq NC7781 Gigabit Server Adapter, ASIC rev. 0x001002 mem 0xf7ff-0xf7ff irq 29 at device 2.0 on pci4 brgphy1: BCM5703 10/100/1000baseTX PHY PHY 1 on miibus1 snip Any help/advice is appreciated, and sorry for following up to myself with this information. ~Paul This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/about-us-legal-email-disclaimer.htm for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/127050: [carp] ipv6 does not work on carp interfaces [regression]
On 8/21/2011 1:47 AM, Ask Bjørn Hansen wrote:
On Aug 19, 2011, at 1:30, Paul Herman wrote:
--010305010708060807000808
Content-Type: application/gzip;
name=carp_ip6_alias.patch.gz
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=carp_ip6_alias.patch.gz
I wanted to try it, but gzip doesn't seem to like that file …
(downloaded from http://www.freebsd.org/cgi/query-pr.cgi?pr=127050cat= )
It's base64 encoded of course -- works for me when I pipe the text into
openssl base64 -d | zcat
(zipped to preserve white spacing) For those craving instant
satisfaction, here it is in plain text.
-Paul.
--- sys/netinet/ip_carp.c.orig 2011-08-19 07:52:56.0 +
+++ sys/netinet/ip_carp.c 2011-08-19 07:15:03.0 +
@@ -1670,9 +1670,11 @@
struct carp_if *cif;
struct in6_ifaddr *ia, *ia_if;
struct ip6_moptions *im6o = sc-sc_im6o;
+ struct in6_multi *in6m;
struct in6_addr in6;
int own, error;
+
error = 0;
if (IN6_IS_ADDR_UNSPECIFIED(sin6-sin6_addr)) {
@@ -1729,8 +1731,6 @@
}
if (!sc-sc_naddrs6) {
- struct in6_multi *in6m;
-
im6o-im6o_multicast_ifp = ifp;
/* join CARP multicast address */
@@ -1745,24 +1745,24 @@
goto cleanup;
im6o-im6o_membership[0] = in6m;
im6o-im6o_num_memberships++;
-
- /* join solicited multicast address */
- bzero(in6, sizeof(in6));
- in6.s6_addr16[0] = htons(0xff02);
- in6.s6_addr32[1] = 0;
- in6.s6_addr32[2] = htonl(1);
- in6.s6_addr32[3] = sin6-sin6_addr.s6_addr32[3];
- in6.s6_addr8[12] = 0xff;
- if (in6_setscope(in6, ifp, NULL) != 0)
- goto cleanup;
- in6m = NULL;
- error = in6_mc_join(ifp, in6, NULL, in6m, 0);
- if (error)
- goto cleanup;
- im6o-im6o_membership[1] = in6m;
- im6o-im6o_num_memberships++;
}
+ /* join solicited multicast address */
+ bzero(in6, sizeof(in6));
+ in6.s6_addr16[0] = htons(0xff02);
+ in6.s6_addr32[1] = 0;
+ in6.s6_addr32[2] = htonl(1);
+ in6.s6_addr32[3] = sin6-sin6_addr.s6_addr32[3];
+ in6.s6_addr8[12] = 0xff;
+ if (in6_setscope(in6, ifp, NULL) != 0)
+ goto cleanup;
+ in6m = NULL;
+ error = in6_mc_join(ifp, in6, NULL, in6m, 0);
+ if (error)
+ goto cleanup;
+ im6o-im6o_membership[1] = in6m;
+ im6o-im6o_num_memberships++;
+
if (!ifp-if_carp) {
cif = malloc(sizeof(*cif), M_CARP,
M_WAITOK|M_ZERO);
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/127050: [carp] ipv6 does not work on carp interfaces [regression]
The following reply was made to PR kern/127050; it has been noted by GNATS. From: Paul Herman pher...@frenchfries.net To: bug-follo...@freebsd.org Cc: Wouter de Jong maddo...@maddog2k.net, Jacek Zapala ja...@it.pl Subject: Re: kern/127050: [carp] ipv6 does not work on carp interfaces [regression] Date: Fri, 19 Aug 2011 10:13:46 +0200 This is a multi-part message in MIME format. --010305010708060807000808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This one's been bothering me too, so I setup a test machine yesterday to figure out what's going on. I see two problems here. First of all, in6_ifinit() (called via in6_control() SIOCAIFADDR_IN6 - in6_update_ifa()) only calls carp_ioctl() on the first IPv6 address. Whereas in the v4 case, carp_ioctl() does get called by in_ifinit() every time. Second of all, carp_set_addr6() (called via carp_ioctl()) only joins the CARP multicast group AND the solicitation group with the first address. The attached patch against 8-STABLE fixes these issues, alias IPs are now pingable. I have not tested actual carp functionality with a 2nd BACKUP carp. What this patch doesn't address is group membership removal when alias IPs are deleted (apparently also broken.) Try it out, if it works for you guys, maybe someone more familiar with in[6]_control() can chime in here and comment on a *real* way to fix this issue. :-) Cheers, -Paul. --010305010708060807000808 Content-Type: application/gzip; name=carp_ip6_alias.patch.gz Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=carp_ip6_alias.patch.gz H4sICDwXTk4CA2NhcnBfaXA2X2FsaWFzLnBhdGNoAJVVa0+jQBT9TH/F9UsDHbDQWvramhof CVlfsZpN1hiCCDobYAhD42Pd/753mNIHtlZJyuvee+7pOXcGwzCAv/JmEuQUf3aTJvauv8sy +qi0TMsyzJ5h9cHsDszeoG3umuUBRJxrhJA19dXS/qDT/lA6HoNhdffaehfI7Doe16AGCvWM feq53sNDBiNocMQcYsBQaAgqDT2fTZMcfozAgnodaJhieuhS5ueRBn9rpMirJL6/zxPz1zSA 0Qick2v38ODqUluLAooSZBkTDNTGahShUx0mzsXhxDk5ODq60kH1BVs316inDUWtoFDUz7AU nkYvKsegsSp5k6au72XpetU7rUHH3qb6AqJSbXUG5gbh7a6p91F4cbWsQnmF59nUz0FAuci/ 4dNwuHiNLuDbwpQG9XRxclcTUtuNWZpTlnCMxjZD7ercN/a574rHIVqzBBZPo5xiYmLHlTZF E+m6QtFB9pzoUKgp5oDg29IacygnBtV2zm3XmbjCD/fmfHJ5fOicOMdHal3MD3IogTXhiBy+ Vl/vieFrW7otJfg3h9uZEU9EDbdFkaFspG8UnuN/xDHBswz6Hs9RohR54lkyVZoN+MNoAmLy YJ4GokvAUbdmuTA6emuvWBnFTcFOUR5ZzsCPAi+ZpsNqzyC+DzL+RNNb8070nAm7nJNM46U8 ToigbixYcRZRn+bBw3pqmHn/FmRMrSO4Dpy+BSxU8V4Tg42dcPVzKbNlSxZPOY6Dar6Eodn6 kNRu3Vp30sYPgVZZHanWusK2iFe8XQlXa3q3VoEpuMiY2E6wkgc591kazP5VsbrPb05PNdjB bE2kVoSXwDGCibziuZzIYjR8V6gp9wkJKvLkfawj5ry/3CM2tFjrrbXw1tjmrRxo8lV7ySfu ki+YSzZ4Sz63lnzfWbLZWPJlX0lVc7LqKvm2qWTZ03Xw2xwlWwwl5e5UfpHEZj37xOB2jTix F0XMV2fmiT1c0+Gs+NDpIgvwOHN/HTjXFz/fz9zfx1cXSPw/VIIrJwgIAAA= --010305010708060807000808-- ___ 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: Debugging dropped shell connections over a VPN
On 07/27/11 06:50, Gary Palmer wrote: On Tue, Jul 26, 2011 at 01:35:16PM -0500, Paul Keusemann wrote: On 07/26/11 08:05, Gary Palmer wrote: On Tue, Jul 26, 2011 at 06:53:59AM -0500, Paul Keusemann wrote: Again, sorry for the sluggish response. On 07/20/11 15:15, Gary Palmer wrote: On Tue, Jul 12, 2011 at 02:26:34PM -0500, Paul Keusemann wrote: On 07/07/11 14:39, Chuck Swiger wrote: On Jul 7, 2011, at 4:45 AM, Paul Keusemann wrote: My setup is something like this: - My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris machines running various OS versions. - My gateway / firewall machine is running FreeBSD-8.1-RELEASE-p1 with ipfw, nat and racoon for the firewall and VPN. The problem is that rlogin, ssh and telnet connections over the VPN get dropped after some period of inactivity. You're probably getting NAT timeouts against the VPN connection if it is left idle. racoon ought to have a config setting called natt_keepalive which sends periodic keepalives-- see whether that's disabled. Regards, Thanks for the suggestions Chuck, sorry it's taken so long to respond but I had to reconfigure and rebuild my kernel to enable IPSEC_NAT_T in order to try this out. One thing that I did not explicitly mention before is that I am routing a network over the VPN. Hi Paul, Even if you are not being NAT'd on the VPN there may be a firewall (or other active network component like a load balancer) with an overflowing state table somewhere at the remote end. We see this frequently where I work with customer networks and the firewall/VPN/network admin denies that its a time out issue so there is likely some device in the network that has a state table and if the connection is idle for a few minutes it gets dropped. Hmmm, this seems likely. Have you had any luck in finding the culprit and resolving the problem? Unfortunately no. We know the problem exists but as a vendor we have very little success in getting the customer to identify the problematic device inside their network as it only seems to affect our connections to them when we are helping them with problems, so there is almost always something more important going on and the timeout issue gets put on the back burner and forgotten. We've worked around it in some places by using the ssh 'ServerAliveInterval' directive to make ssh send packets and keep the session open even if we're idle, but that doesn't always work. OK, I found the ClientAliveInterval, and ClientAliveCountMax setting in the ssh_config man page. I assume these are what you are referring to. I tried setting ClientAliveInterval to 15 seconds with ClientAliveCountMax set to 3 and this seems to help. I've only tried this a couple of times but I have seen an ssh session stay alive for over an hour. The bad news is that the sessions are still getting dropped, at least now I know when it happens. Now I'm getting the following message: Received disconnect from 10.64.20.69: 2: Timeout, your session not responding. From a quick perusal of the openssh source, it is not obvious whether this message is coming from the client or the server side. Initially, because the keep alive timer is a server side setting, I assumed the message was coming from the server side but if the session is not responding how is the message getting to the client? If it is a client side problem, then I have much more flexibility to fix. All I can do is whine about server side problems. Hi Paul, ServerAliveInterval is actually a client setting. e.g. put this in your ~/.ssh/config file host * ServerAliveInterval 15 will set the client to ping the server every 15 seconds and try to keep the connection alive. You can replace '*' you want to be more targeted in your configuration. Ah, I see. I was looking at the Solaris ssh_config man page. The OpenSSH ssh_config man page is third in the sequence. The ServerAlive* options are not documented in the Solaris ssh_config man page. I'll try it out too. Thanks. I've never played with the server side settings for various reasons. Regards, Gary ___ 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 -- Paul Keusemannpkeu...@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378 ___ 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: Debugging dropped shell connections over a VPN
Once again, apologies for my sluggish response. The VPN problem is a background job worked on when I can or when I'm too annoyed by it to do anything else. On 07/12/11 17:42, Chuck Swiger wrote: On Jul 12, 2011, at 12:26 PM, Paul Keusemann wrote: So, any other ideas on how to debug this? Gather data with tcpdump. If you do it on one of the VPN endpoints, you ought to see the VPN contents rather than just packets going by in the encrypted tunnel. I assume by endpoint, you are talking about the target of the remote shell. Unfortunately, running tcpdump on the endpoint shows only the initial negotiation (and any interactive keyboard traffic) but nothing to indicate the connection has been dropped or timed out. If I can get some time when I don't actually need to use the VPN for work, I'm going to try to run tcpdump on the tunnel to see if there's anything going across it that might shed some light on the cause of the dropped connections. Anybody know how to get racoon to log everything to one file? Right now, depending on the log level, I am getting messages in racoon.log (specified with -l at startup), messages and debug.log. It would really be nice to have just one log to look at. This is likely governed by /etc/syslog.conf, but if you specify -l then racoon shouldn't use syslog logging. My syslog.conf foo is not good but it seems that some stuff from racoon always ends up in the messages file, even when the -l option to racoon is specified. Thanks again for the tips. -- Paul Keusemannpkeu...@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378 ___ 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: Debugging dropped shell connections over a VPN
Again, sorry for the sluggish response. On 07/20/11 15:15, Gary Palmer wrote: On Tue, Jul 12, 2011 at 02:26:34PM -0500, Paul Keusemann wrote: On 07/07/11 14:39, Chuck Swiger wrote: On Jul 7, 2011, at 4:45 AM, Paul Keusemann wrote: My setup is something like this: - My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris machines running various OS versions. - My gateway / firewall machine is running FreeBSD-8.1-RELEASE-p1 with ipfw, nat and racoon for the firewall and VPN. The problem is that rlogin, ssh and telnet connections over the VPN get dropped after some period of inactivity. You're probably getting NAT timeouts against the VPN connection if it is left idle. racoon ought to have a config setting called natt_keepalive which sends periodic keepalives-- see whether that's disabled. Regards, Thanks for the suggestions Chuck, sorry it's taken so long to respond but I had to reconfigure and rebuild my kernel to enable IPSEC_NAT_T in order to try this out. One thing that I did not explicitly mention before is that I am routing a network over the VPN. Hi Paul, Even if you are not being NAT'd on the VPN there may be a firewall (or other active network component like a load balancer) with an overflowing state table somewhere at the remote end. We see this frequently where I work with customer networks and the firewall/VPN/network admin denies that its a time out issue so there is likely some device in the network that has a state table and if the connection is idle for a few minutes it gets dropped. Hmmm, this seems likely. Have you had any luck in finding the culprit and resolving the problem? Regards, Gary ___ 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 -- Paul Keusemannpkeu...@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378 ___ 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: Debugging dropped shell connections over a VPN
On 07/26/11 08:05, Gary Palmer wrote: On Tue, Jul 26, 2011 at 06:53:59AM -0500, Paul Keusemann wrote: Again, sorry for the sluggish response. On 07/20/11 15:15, Gary Palmer wrote: On Tue, Jul 12, 2011 at 02:26:34PM -0500, Paul Keusemann wrote: On 07/07/11 14:39, Chuck Swiger wrote: On Jul 7, 2011, at 4:45 AM, Paul Keusemann wrote: My setup is something like this: - My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris machines running various OS versions. - My gateway / firewall machine is running FreeBSD-8.1-RELEASE-p1 with ipfw, nat and racoon for the firewall and VPN. The problem is that rlogin, ssh and telnet connections over the VPN get dropped after some period of inactivity. You're probably getting NAT timeouts against the VPN connection if it is left idle. racoon ought to have a config setting called natt_keepalive which sends periodic keepalives-- see whether that's disabled. Regards, Thanks for the suggestions Chuck, sorry it's taken so long to respond but I had to reconfigure and rebuild my kernel to enable IPSEC_NAT_T in order to try this out. One thing that I did not explicitly mention before is that I am routing a network over the VPN. Hi Paul, Even if you are not being NAT'd on the VPN there may be a firewall (or other active network component like a load balancer) with an overflowing state table somewhere at the remote end. We see this frequently where I work with customer networks and the firewall/VPN/network admin denies that its a time out issue so there is likely some device in the network that has a state table and if the connection is idle for a few minutes it gets dropped. Hmmm, this seems likely. Have you had any luck in finding the culprit and resolving the problem? Unfortunately no. We know the problem exists but as a vendor we have very little success in getting the customer to identify the problematic device inside their network as it only seems to affect our connections to them when we are helping them with problems, so there is almost always something more important going on and the timeout issue gets put on the back burner and forgotten. We've worked around it in some places by using the ssh 'ServerAliveInterval' directive to make ssh send packets and keep the session open even if we're idle, but that doesn't always work. OK, I found the ClientAliveInterval, and ClientAliveCountMax setting in the ssh_config man page. I assume these are what you are referring to. I tried setting ClientAliveInterval to 15 seconds with ClientAliveCountMax set to 3 and this seems to help. I've only tried this a couple of times but I have seen an ssh session stay alive for over an hour. The bad news is that the sessions are still getting dropped, at least now I know when it happens. Now I'm getting the following message: Received disconnect from 10.64.20.69: 2: Timeout, your session not responding. From a quick perusal of the openssh source, it is not obvious whether this message is coming from the client or the server side. Initially, because the keep alive timer is a server side setting, I assumed the message was coming from the server side but if the session is not responding how is the message getting to the client? If it is a client side problem, then I have much more flexibility to fix. All I can do is whine about server side problems. Paul Gary ___ 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 -- Paul Keusemannpkeu...@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378 ___ 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: Debugging dropped shell connections over a VPN
On 07/07/11 14:39, Chuck Swiger wrote:
On Jul 7, 2011, at 4:45 AM, Paul Keusemann wrote:
My setup is something like this:
- My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris machines
running various OS versions.
- My gateway / firewall machine is running FreeBSD-8.1-RELEASE-p1 with ipfw,
nat and racoon for the firewall and VPN.
The problem is that rlogin, ssh and telnet connections over the VPN get dropped
after some period of inactivity.
You're probably getting NAT timeouts against the VPN connection if it is left
idle. racoon ought to have a config setting called natt_keepalive which sends
periodic keepalives-- see whether that's disabled.
Regards,
Thanks for the suggestions Chuck, sorry it's taken so long to respond
but I had to reconfigure and rebuild my kernel to enable IPSEC_NAT_T in
order to try this out.
One thing that I did not explicitly mention before is that I am routing
a network over the VPN.
I did not have previously NAT-Traversal enabled nor was it configured in
my kernel. After reconfiguring, compiling and installing the new
kernel, I added the following to the phase 1 configuration for my VPN:
timer
{
# Default is 20 seconds.
natt_keepalive 10 sec;
}
# Enable NAT traversal.
#nat_traversal on;
nat_traversal force;
# Enable IKE fragmentation.
ike_frag on;
# Enable ESP fragmentaion at 552 bytes.
esp_frag 552;
The only immediately noticeable change is that I am no longer getting
the following warnings at racoon startup:
WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): UDP_ENCAP
Invalid argument
I assume this is the result of adding IPSEC_NAT_T to the kernel config.
My shell connections are still being dropped, so I'm pretty much back to
square one.
So, any other ideas on how to debug this?
Anybody know how to get racoon to log everything to one file? Right
now, depending on the log level, I am getting messages in racoon.log
(specified with -l at startup), messages and debug.log. It would really
be nice to have just one log to look at.
--
Paul Keusemannpkeu...@visi.com
4266 Joppa Court (952) 894-7805
Savage, MN 55378
___
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
Multiple IPv6 ISPs
Hi, At one of my customers we have had 2 ISPs for a long time but now we have to support IPv6 too. In the IPv4 world I used ipfw for policy-based routing to separate traffic from the two public address ranges: ipfw add 1010 allow ip from any to MY_IP_RANGES ipfw add 1020 fwd ISP1_GW ip from ISP1_SUBNET to any ipfw add 1030 fwd ISP2_GW ip from ISP2_SUBNET to any When I try the same with IPv6, it appears that ipfw(8) does not support an IPv6 destination with the fwd statement, the packet matching part seems to work fine. This appears documented in bin/117214 (Oct 2007) but never solved. Before asking the list I went looking for other options, setfib came to mind but it appears that setfib only works on IPv4, is that correct or am I overlooking something? Pf is used for firewalling and doing both filtering and policy based routing in pf doesn't work. Anyway, how do other people solve this? I need to run services on both address ranges so flipping a default gateway when pinging the next hop fails does not solve it for me. Soon, having IPv6 is no longer an option but rather a necessity. Regards, Paul Schenkeveld ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/142197: [ndis] [patch] ndis is missing media status reporting
On Wed, Jan 6, 2010 at 1:04 PM, ga...@freebsd.org wrote: Synopsis: [ndis] [patch] ndis is missing media status reporting State-Changed-From-To: open-patched State-Changed-By: gavin State-Changed-When: Wed Jan 6 12:02:52 UTC 2010 State-Changed-Why: Committed to HEAD in r201620 Responsible-Changed-From-To: freebsd-net-rpaulo Responsible-Changed-By: gavin Responsible-Changed-When: Wed Jan 6 12:02:52 UTC 2010 Responsible-Changed-Why: Over to rpaulo as MFC reminder http://www.freebsd.org/cgi/query-pr.cgi?pr=142197 Please close this bug report. ___ 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: Broadcom BCM57765 support?
On 04/05/2011 18:05, YongHyeon PYUN wrote: FYI: Committed to HEAD(r221445). I've been away from the machines with this chipset for the past week so have not finished the testing, but can report that the initial tests I did involving normal use, jumbo frames, v4 and v6 etc. all worked fine and throughput was good. Once I have done a thorough test of the NIC I will post a report here. Paul. ___ 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: Broadcom BCM57765 support?
On 19/04/2011 23:09, YongHyeon PYUN wrote: Here is experimental patch for BCM57765 family controllers. I don't have these controllers so the patch was not tested at all except compile. Recent Broadcom controllers like BCM57765 support EEE(Energy Efficient Ethernet) feature but it is not yet supported by the patch. Many thanks for this patch. The patch wouldn't apply cleanly to either the 8.2-release source or to the latest if_bge / if_bgereg so I had to do it manually; but that wasn't too much of a problem. What revision should I have tried to apply the patch to? Things are not fully working yet after the patch is applied though. The current state is that the device is recognised, MAC address detected OK, link state detected OK; you can ifconfig up the interface without a problem. However, I'm seeing bge0: watchdog timeout -- resetting messages shortly after attempting to ping something on the LAN. The machine being pinged doesn't show up in the ARP cache. Looking at the switch that its connected to, I see the mac address learned on the port, and the received packet and byte counts incrementing with no errors so I believe that the machine is successfully transmitting frames but not able to receive them properly. The switch stats show that the switch is transmitting frames to the machine. Also it would good to see the output of pciconf -lcbv and dmesg after applying the patch. The machine in question is a 2010 Mac Mini (model rev A1347) - this has a number of features that make FreeBSD an interesting challenge. The kernel I'm using is a normal 8.2-GENERIC with another very minor tweak to stop the Nvidia MCP89 ata controller from being used in SATA mode (this doesn't work - Linux has a workaround based on using UDMA). Attached is a dmesg, pciconf, and the output of sysctl -a dev.bge.0 after the patch was applied. If there is any other debugging information I need to get to help please let me know. Once we have this working I'll willingly give it some thorough proper testing. Thanks again, Paul. Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-RELEASE #1: Wed Apr 20 08:58:24 UTC 2011 r...@badger.prt.org:/usr/src/sys/amd64/compile/GENERIC-TEST2 amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz (2389.26-MHz K8-class CPU) Origin = GenuineIntel Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x408e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 1780576256 (1698 MB) ACPI APIC Table: APPLE Apple00 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 Version 1.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: APPLE Apple00 on motherboard acpi0: [ITHREAD] acpi_ec0: Embedded Controller: GPE 0x57, ECDT port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) unknown: I/O range not supported acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter HPET frequency 2500 Hz quality 900 Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge on acpi0 pci0: ACPI PCI bus on pcib0 pci0: memory, RAM at device 0.1 (no driver attached) pci0: memory, RAM at device 1.0 (no driver attached) pci0: memory, RAM at device 1.1 (no driver attached) pci0: memory, RAM at device 1.2 (no driver attached) pci0: memory, RAM at device 1.3 (no driver attached) pci0: memory, RAM at device 2.0 (no driver attached) pci0: memory, RAM at device 2.1 (no driver attached) isab0: PCI-ISA bridge port 0x2100-0x21ff at device 3.0 on pci0 isa0: ISA bus on isab0 pci0: memory, RAM at device 3.1 (no driver attached) pci0: serial bus, SMBus at device 3.2 (no driver attached) pci0: memory, RAM at device 3.3 (no driver attached) pci0: processor at device 3.4 (no driver attached) ohci0: OHCI (generic) USB controller mem 0x9358a000-0x9358afff irq 18 at device 4.0 on pci0 ohci0: [ITHREAD] usbus0: OHCI (generic) USB controller on ohci0 ehci0: EHCI (generic) USB 2.0 controller mem 0x9358b100-0x9358b1ff irq 19 at device 4.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.10 usbus1: EHCI (generic) USB 2.0 controller on ehci0 ohci1: OHCI (generic) USB controller mem 0x93589000
Re: Broadcom BCM57765 support?
Hi, On 20/04/2011 14:16, Marius Strobl wrote: Looks like brgphy(4) also needs to be taught about this hardware. Could you please provide the corresponding part of a verbose dmesg? Hopefully this covers everything that you might need: pcib4: slot 0 INTA is routed to irq 18 found- vendor=0x14e4, dev=0x16bc, revid=0x00 domain=0, bus=4, slot=0, func=1 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0x9312, size 16, enabled pcib4: requested memory range 0x9312-0x9312: good pcib0: matched entry for 0.22.INTB (src \\_SB_.PCI0.Z00O:0) pci_link13: Picked IRQ 19 with weight 1 pcib0: slot 22 INTB routed to irq 19 via \\_SB_.PCI0.Z00O pcib4: slot 0 INTB is routed to irq 19 bge0: Broadcom unknown BCM57765, ASIC rev. 0x57785000 mem 0x9310-0x9310,0x9311-0x9311 irq 18 at device 0.0 on pci4 bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0x9310 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 56 bge0: using IRQ 256 for MSI bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E bge0: Disabling fastboot bge0: Disabling fastboot miibus0: MII bus on bge0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus0 ukphy0: OUI 0x00d897, model 0x0024, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: c4:2c:03:08:0b:9d bge0: [MPSAFE] bge0: [FILTER] Many thanks, Paul. ___ 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: Broadcom BCM57765 support?
Hi, On 20/04/2011 14:44, Marius Strobl wrote: Hrm, looks like neither NetBSD nor OpenBSD support this variant so far, however Linux also doesn't seem to have special handling for it. Could you please give the attached patch in addition to the existing one a try? I've added your patch to brgphy as well - but at a user level I'm still seeing the same thing: - Ethernet frames are transmitted by the box, switch sees them with no errors. - Frames received don't seem to make it to/beyond the driver. - After I hit CTRL-C on the non-working ping, I get a bge0: watchdog timeout -- resetting message. If I tcpdump the interface, I see nothing, but the dev.bge.0.stats counters are incrementing when I attempt to ping. The switch is showing counts on both its tx and rx packets counters with no errors. Is there somewhere I need to add more debug in the driver to understand what it is doing? The current dmesg looks like: bge0: Broadcom unknown BCM57765, ASIC rev. 0x57785000 mem 0x9310-0x9310,0x9311-0x9311 irq 18 at device 0.0 on pci4 bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0x9310 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 56 bge0: using IRQ 256 for MSI bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E bge0: Disabling fastboot bge0: Disabling fastboot miibus0: MII bus on bge0 brgphy0: BCM57785 10/100/1000baseTX PHY PHY 1 on miibus0 brgphy0: OUI 0x00d897, model 0x0024, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: c4:2c:03:08:0b:9d bge0: [MPSAFE] bge0: [FILTER] Paul. ___ 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
Broadcom BCM57765 support?
Hi, The bge driver doesn't support this chipset yet and I was wondering if anyone has looked at implementing it. NetBSD looks like it has support for it. Now I may be wrong here, but it appears that the BCM57765 is similar to other devices based on the NetBSD if_bge.c source version 1.194. I've tried applying the NetBSD changes to the FreeBSD bge source but I don't know enough about the hardware and the code is different enough that I haven't made it very far. I can get a patched 8.2 kernel to detect the device, complain that the ASIC is unknown, read the MAC address correctly and determine there is link but as soon as you attempt to ifconfig up the interface the machine locks up. I'm happy to try and port this over but need a nudge in the right direction from someone who knows the code. Thanks, Paul. ___ 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: bwi vs. bwn
On Fri, Feb 18, 2011 at 11:26 PM, grarpamp grarp...@gmail.com wrote: Doesn't FreeBSD have some sort of ndiswrapper function for this? http://www.broadcom.com/support/802.11/linux_sta.php NDISulator, ndis(4). Hmm, maybe that only applies to the Windows driver bundles as distributed by the vendors (Dell, HP, Lenovo, etc). Or from Microsoft itself as part of the OS. And not to this Linux thing. You need inf and sys file(s), Windows drivers. Everything is explained in documentation. ___ 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: bwi vs. bwn
On Fri, Feb 18, 2011 at 9:54 PM, grarpamp grarp...@gmail.com wrote: Doesn't FreeBSD have some sort of ndiswrapper function for this? NDISulator, ndis(4). ___ 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: Carp seems completely broken on 8.2-RC2 and 8.2-PRERELEASE
On Mon, Jan 17, 2011 at 01:05:31PM +0100, Daniel Hartmeier wrote: On Sun, Jan 16, 2011 at 01:41:22PM +0100, Paul Schenkeveld wrote: There is an ARP request which is replied to by the carp master (test). the ping to the carp address does not even appear on the sis4 interface of test1. Everything looks fine, except for the fact that the ping (echo request) doesn't get to test1's sis4. Are you sure the problem isn't with the switch? Have you tried resetting it? Or replacing it with another one (where you could check the MAC address table, etc.)? The switch has been power-cycled, no change. Only 3 ports are wired, to test1, test2 and test3. I'm not in the office right now, can replace the switch tonight, but read on... You'd get this behavior if the switch had learned carp4's virtual MAC address (00:00:5e:00:01:68) on another port. You're not using vhid 104 (:68 in the virtual MAC) on other ports of that switch, are you? test3 has no carp nor vrrp so vhid 104 is not in use anywhere else. Tcpdump shows only carp (vrrp) packets from test1 one per second. sis3 of test1 and test2 are connected by a cross-cable. IP addresses are 10.3.0.1/24 (carp3, vhid 103, test1 is master, test2 is backup), 10.3.0.2/24 for sis3 on test1 and 10.3.0.3 for sis3 on test2. On test1 I can ping 10.3.0.1 (which test1 is carp master for), from test2 I can't ping 10.3.0.1. A tcpdump on sis3 on test1 shows ARP request and reply, but no icmp echo-request. The arp entry on test2 looks OK: test2 # arp 10.3.0.1 ? (10.3.0.1) at 00:00:5e:00:01:67 on sis3 expires in 800 seconds [ethernet] On test2 I can ping 10.3.0.2 and 10.4.0.2 (the addresses on sis3 and sis4 of test1) and see the normal arp-request/arp-reply/icmp-echoreq/ icmp-echoreply sequence using tcpdump. Daniel Regards, Paul Schenkeveld ___ 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
sis(4) broken on 8.2 [Re: Carp seems completely broken on 8.2-RC2 and 8.2-PRERELEASE]
On Sun, Jan 16, 2011 at 01:41:22PM +0100, Paul Schenkeveld wrote: Hi, Trying to upgrade two Soekris firewalls to 8-STABLE or 8.2-PRERELEASE it appears that carp doesn't work at all. I've set up carp like I've done on many firewall pairs before and they all work correctly. With google, nor in the mailing lists, I could find anything about changes in the way carp get configured but if I missed something I'd be happy to hear that it's my fault. Here's the setup: net5501 test3 10.4.0.4/24 | -+- | | net4801 net4801 test1 test2 sis4: 10.4.0.2/24 sis4: 10.4.0.3/24 carp4:10.4.0.1/24 carp4:10.4.0.1/24 | | | | | | | | | | | | | | | | sis[0-3] connected to other networks, see explanation below. When I ping from test3 to 10.4.0.1, I see the following traffic using tcpdump: test3 # tcpdump -e -n -i vr3 not vrrp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vr3, link-type EN10MB (Ethernet), capture size 96 bytes 12:09:35.121831 00:00:24:c9:30:ff ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.4.0.1 tell 10.4.0.4, length 46 12:09:35.122144 00:00:24:c3:49:91 00:00:24:c9:30:ff, ethertype ARP (0x0806), length 60: Reply 10.4.0.1 is-at 00:00:5e:00:01:68, length 46 12:09:35.122173 00:00:24:c9:30:ff 00:00:5e:00:01:68, ethertype IPv4 (0x0800), length 98: 10.4.0.4 10.4.0.1: ICMP echo request, id 40482, seq 0, length 64 test1 # tcpdump -e -n -i sis4 not vrrp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on sis4, link-type EN10MB (Ethernet), capture size 96 bytes 12:09:34.977570 00:00:24:c9:30:ff ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.4.0.1 tell 10.4.0.4, length 46 12:09:34.977705 00:00:24:c3:49:91 00:00:24:c9:30:ff, ethertype ARP (0x0806), length 42: Reply 10.4.0.1 is-at 00:00:5e:00:01:68, length 28 test2 # dump -e -n -i sis4 not vrrp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on sis4, link-type EN10MB (Ethernet), capture size 96 bytes 12:09:35.090050 00:00:24:c9:30:ff ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.4.0.1 tell 10.4.0.4, length 46 There is an ARP request which is replied to by the carp master (test). the ping to the carp address does not even appear on the sis4 interface of test1. This is the kernel config for test1 and test2: include GENERIC device carp makeoptions MODULES_OVERRIDE= The relevant rc.conf bits: on test1 hostname=test1 cloned_interfaces=carp1 carp2 carp3 carp4 ifconfig_sis0=xxx.xxx.xxx.41/26 ifconfig_sis1=10.1.0.2/24 ifconfig_sis2=10.2.0.2/24 ifconfig_sis3=10.3.0.2/24 ifconfig_sis4=10.4.0.2/24 ifconfig_carp1=10.1.0.1/24 vhid 101 pass abcd1234 advskew 0 ifconfig_carp2=10.2.0.1/24 vhid 102 pass abcd1234 advskew 0 ifconfig_carp3=10.3.0.1/24 vhid 103 pass abcd1234 advskew 0 ifconfig_carp4=10.4.0.1/24 vhid 104 pass abcd1234 advskew 0 on test2 hostname=test2 cloned_interfaces=carp1 carp2 carp3 carp4 ifconfig_sis0=xxx.xxx.xxx.42/26 ifconfig_sis1=10.1.0.3/24 ifconfig_sis2=10.2.0.3/24 ifconfig_sis3=10.3.0.3/24 ifconfig_sis4=10.4.0.3/24 ifconfig_carp1=10.1.0.1/24 vhid 101 pass abcd1234 advskew 100 ifconfig_carp2=10.2.0.1/24 vhid 102 pass abcd1234 advskew 100 ifconfig_carp3=10.3.0.1/24 vhid 103 pass abcd1234 advskew 100 ifconfig_carp4=10.4.0.1/24 vhid 104 pass abcd1234 advskew 100 In /etc/sysctl.conf: net.inet.carp.preempt=1 Ifconfig output: test1 # ifconfig sis4 sis4: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=83808VLAN_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC,LINKSTATE ether 00:00:24:c3:49:91 inet 10.4.0.2 netmask 0xff00 broadcast 10.4.0.255 media: Ethernet autoselect (100baseTX full-duplex) status: active test1 # ifconfig carp4 carp4: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 10.4.0.1 netmask 0xff00 carp: MASTER vhid 104 advbase 1 advskew 0 test2 # ifconfig sis4 sis4: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=83808VLAN_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC,LINKSTATE ether 00:00:24:c3:49:7d inet 10.4.0.3 netmask 0xff00 broadcast
Re: sis(4) broken on 8.2 [Re: Carp seems completely broken on 8.2-RC2 and 8.2-PRERELEASE]
Hello, On Mon, Jan 17, 2011 at 02:26:24PM -0800, Pyun YongHyeon wrote: Since you didn't post dmesg output I'm not sure what kind of controller you have but I guess it would be NS8381[56]. I overhauled sis(4) to make it work on all architectures so one of change, probably r212119, could be cause of the issue. Due to lack of SiS controllers I didn't touch multicast handling part so some part of code still relies on old wrong behavior of driver. Would you try attached patch and let me know whether it makes any difference? Hmm, unfortunately it seems the patch above may not work since NS data sheet says that filter function should be disabled before touching other bits in the register. Try this one instead. As far as I can tell, both patches work for me. Your second patch is on my production firewalls now so if anthing comes up over the coming days I'll keep you informed. I've tested carp, both failover to backup and fallback (preemption) with IPv4 and with IPv6, all seems to work now. Thannks again for your patches, hope you can get them into 8.2. Regards, Paul Schenkeveld ___ 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 seems completely broken on 8.2-RC2 and 8.2-PRERELEASE
mtu 1500 inet 10.4.0.1 netmask 0xff00 carp: BACKUP vhid 104 advbase 1 advskew 100 There are no packet filters in place, sis1, sis2 and sis3 are wired through cross-cables from test1 to test2, so no traffic there except for carp. The sis4 interfaces and vr3 of test3 are on a dumb switch with no other stuff connected. Setting net.inet.carp.log=7 does not result in any console/dmesg/messages output. I see carp traffic on sis4 which appears normal except that I don't understand the addrs(7): part but that used to be there on 8.0/8.1 firewalls too: 12:26:52.387140 00:00:5e:00:01:68 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0x10, ttl 255, id 61070, offset 0, flags [DF], proto VRRP (112), length 56) 10.4.0.2 224.0.0.18: VRRPv2, Advertisement, vrid 104, prio 0, authtype none, intvl 1s, length 36, addrs(7): 198.145.25.33,1.75.182.226,80.169.106.108, 170.107.157.42,147.165.174.125,42.254.15.27,182.184.82.166 12:26:53.387903 00:00:5e:00:01:68 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0x10, ttl 255, id 61479, offset 0, flags [DF], proto VRRP (112), length 56) 10.4.0.2 224.0.0.18: VRRPv2, Advertisement, vrid 104, prio 0, authtype none, intvl 1s, length 36, addrs(7): 101.233.35.135,163.243.214.16,230.125.241.59, 123.57.190.52,104.246.131.251,255.69.201.65,61.158.20.122 Regards, Paul Schenkeveld ___ 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
ndis: fix panic on i386
Hi,
Following patch fix panic on i386 for drivers using such functions.
Those two functions take 64-bit variable(s) for their arguments.
On i386 that takes additional 32-bit variable per argument.
This is required so that windrv_wrap() can correctly wrap function that
miniport driver calls with stdcall convention.
Similar explanation is provided in subr_ndis.c for other functions.
On amd64 we do not use these numbers.
diff --git a/sys/compat/ndis/subr_ntoskrnl.c b/sys/compat/ndis/subr_ntoskrnl.c
index f169de5..0335561 100644
--- a/sys/compat/ndis/subr_ntoskrnl.c
+++ b/sys/compat/ndis/subr_ntoskrnl.c
@@ -4212,8 +4212,8 @@ image_patch_table ntoskrnl_functbl[] = {
IMPORT_FFUNC(ExInterlockedAddLargeStatistic, 2),
IMPORT_SFUNC(IoAllocateMdl, 5),
IMPORT_SFUNC(IoFreeMdl, 1),
- IMPORT_SFUNC(MmAllocateContiguousMemory, 2),
- IMPORT_SFUNC(MmAllocateContiguousMemorySpecifyCache, 5),
+ IMPORT_SFUNC(MmAllocateContiguousMemory, 2 + 1),
+ IMPORT_SFUNC(MmAllocateContiguousMemorySpecifyCache, 5 + 3),
IMPORT_SFUNC(MmFreeContiguousMemory, 1),
IMPORT_SFUNC(MmFreeContiguousMemorySpecifyCache, 3),
IMPORT_SFUNC_MAP(MmGetPhysicalAddress, pmap_kextract, 1),
___
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
ndis: properly allocate memory
Hi,
Attached patch resolves buggy allocation of memory in NDISulator.
Correct behavior is to not ignore parameters specified by miniport driver.
diff --git a/src/sys/compat/ndis/subr_ntoskrnl.c
b/src/sys/compat/ndis/subr_ntoskrnl.c
index 04184ae..f169de5 100644
--- a/src/sys/compat/ndis/subr_ntoskrnl.c
+++ b/src/sys/compat/ndis/subr_ntoskrnl.c
@@ -2426,12 +2426,9 @@ MmAllocateContiguousMemorySpecifyCache(size, lowest,
highest,
uint64_tboundary;
uint32_tcachetype;
{
- void *addr;
- size_t pagelength = roundup(size, PAGE_SIZE);
-
- addr = ExAllocatePoolWithTag(NonPagedPool, pagelength, 0);
- return (addr);
+ return (contigmalloc(size, M_DEVBUF, M_ZERO|M_NOWAIT, lowest,
+ highest, PAGE_SIZE, boundary));
}
static void
@@ -2447,7 +2444,7 @@ MmFreeContiguousMemorySpecifyCache(base, size, cachetype)
uint32_tsize;
uint32_tcachetype;
{
- ExFreePool(base);
+ contigfree(base, size, M_DEVBUF);
}
static uint32_t
___
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: Problems with 8.1, PPPoE server, and Cisco client
On 26/10/2010 18:55, Paul Thornton wrote: I've been taking another look at this after being dragged off onto other things for a few days, and hopefully have some more information that might help point in the right direction for a fix / where to debug next. On 20/10/2010 17:16, Julian Elischer wrote: have you tried to connect this cisco router to anything else pppoe? (take it home and make it connect to your ISP for example?) The Cisco client does work to a Cisco router acting as a PPPoE server - I used a 891 (client) to a 3945 (server) and using an established setup that is known to work, I collected a happy tcpdump. Of course that doesn't tell us why there was such an issue with the FreeBSD ppp server and it looks very similar to me. I'm also going to give mpd a go and see if that works - but if it tries the same config options as pppoed then I may be straight back to where I am now. Thanks to everyone for their help with this. So here is the dump from a known good setup, IOS at both ends - starting from the CHAP success point again. This time, both ends play the game and agree amongst themselves what they will and won't do as expected (many thanks to Ian here for the commentary as to what was going on in the exchanges I have): 20:29:10.200860 PPPoE [ses 0x13] CHAP, Response (0x02), id 1, Value 8f917e3cd84fd4b3a5e8b705655bf16772d0cd1462392eed8bb4ab0ccb7f75bb2d01695ac26cdc07127b4fb3435a279a01, Name vt123456...@vdsl01.v 20:29:14.501312 PPPoE [ses 0x13] CHAP, Success (0x03), id 1, Msg 20:29:14.501702 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 109.71.168.123 0x: 6d47 a87b 20:29:14.504344 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 0.0.0.0 0x: 20:29:14.504497 PPPoE [ses 0x13] unknown PPP protocol (0x8207) 0x: 0101 0004 20:29:14.504669 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0201 000a IP-Addr Option (0x03), length 6: 109.71.168.123 0x: 6d47 a87b 20:29:14.505200 PPPoE [ses 0x13] IPCP, Conf-Nack (0x03), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0301 000a IP-Addr Option (0x03), length 6: 109.71.174.50 0x: 6d47 ae32 20:29:14.505290 PPPoE [ses 0x13] LCP, Prot-Reject (0x08), id 2, length 12 encoded length 10 (=Option(s) length 6) 0x: c021 0802 000a Rejected unknown Protocol (0x8207) Rejected Packet 0x: 0101 0006 20:29:14.505800 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 2, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0102 000a IP-Addr Option (0x03), length 6: 109.71.174.50 0x: 6d47 ae32 20:29:14.506753 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 2, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0202 000a IP-Addr Option (0x03), length 6: 109.71.174.50 0x: 6d47 ae32 20:29:23.247975 PPPoE [ses 0x13] IP (tos 0x0, ttl 255, id 35, offset 0, flags [none], proto ICMP (1), length 100) 109.71.174.50 217.65.161.4: ICMP echo request, id 10, seq 0, length 80 20:29:23.257872 PPPoE [ses 0x13] IP (tos 0x0, ttl 61, id 51771, offset 0, flags [none], proto ICMP (1), length 100) 217.65.161.4 109.71.174.50: ICMP echo reply, id 10, seq 0, length 80 The ping here is the start of real data flowing - I used this setup for about 30 minutes of web browsing with no problems. Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Problems with 8.1, PPPoE server, and Cisco client
Hi folks, Keeping the list archives updated for any poor soul that has a similar problem in future... On 26/10/2010 18:55, Paul Thornton wrote: I'm also going to give mpd a go and see if that works - but if it tries the same config options as pppoed then I may be straight back to where I am now. The verdict with mpd is exactly the same - the Cisco takes exception to the IPCP request immediately following the successful auth, and tears down the connection. I'm going to take this to the Cisco TAC and see if they can suggest anything that may be causing this as it makes no sense at all when all other clients I try work. Paul. ___ 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: Problems with 8.1, PPPoE server, and Cisco client
On 09/11/2010 20:16, Paul Thornton wrote: Sorry for that unedited copy of the last mail to the list. Finger trouble in mail client. Must try harder! Paul. ___ 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: Polling slows down bandwidth
Hi, On 29/10/2010 18:23, Chuck Swiger wrote: On Oct 28, 2010, at 11:39 PM, Коньков Евгений wrote: so using polling on gigabit NICs is a bottle neck? and is cause of low performance, is not? Simple answer is yes. It should be possible that you could tune polling to get similar performance, or at least better performance than you see now, but the additional hardware capabilities of gigabit NICs are likely to outperform polling mode, just as polling mode can generally outperform old 100MBs ethernet NICs. I have been using polling for a long time with em and fxp interfaces on 6.2 and 4.9 boxes that are working as routers. I've been doing testing with FreeBSD 8 and em interfaces recently, and my experience agrees with Chuck's statement - that polling makes things worse when you use new (anything in the last 2 or 3 years) hardware with good quality gigabit ethernet interfaces. I've only really worked with bge and em but they have good high performance without polling in 8.0 and 8.1 Paul. ___ 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: Problems with 8.1, PPPoE server, and Cisco client
I've been taking another look at this after being dragged off onto other things for a few days, and hopefully have some more information that might help point in the right direction for a fix / where to debug next. On 20/10/2010 17:16, Julian Elischer wrote: have you tried to connect this cisco router to anything else pppoe? (take it home and make it connect to your ISP for example?) The Cisco client does work to a Cisco router acting as a PPPoE server - I used a 891 (client) to a 3945 (server) and using an established setup that is known to work, I collected a happy tcpdump. Of course that doesn't tell us why there was such an issue with the FreeBSD ppp server and it looks very similar to me. I'm also going to give mpd a go and see if that works - but if it tries the same config options as pppoed then I may be straight back to where I am now. Thanks to everyone for their help with this. So here is the dump from a known good setup, IOS at both ends - starting from the CHAP success point again. This time, both ends play the game and agree amongst themselves what they will and won't do as expected (many thanks to Ian here for the commentary as to what was going on in the exchanges I have): 20:29:10.200860 PPPoE [ses 0x13] CHAP, Response (0x02), id 1, Value 8f917e3cd84fd4b3a5e8b705655bf16772d0cd1462392eed8bb4ab0ccb7f75bb2d01695ac26cdc07127b4fb3435a279a01, Name vt123456...@vdsl01.v 20:29:14.501312 PPPoE [ses 0x13] CHAP, Success (0x03), id 1, Msg 20:29:14.501702 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 109.71.168.123 0x: 6d47 a87b 20:29:14.504344 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 0.0.0.0 0x: 20:29:14.504497 PPPoE [ses 0x13] unknown PPP protocol (0x8207) 0x: 0101 0004 20:29:14.504669 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0201 000a IP-Addr Option (0x03), length 6: 109.71.168.123 0x: 6d47 a87b 20:29:14.505200 PPPoE [ses 0x13] IPCP, Conf-Nack (0x03), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0301 000a IP-Addr Option (0x03), length 6: 109.71.174.50 0x: 6d47 ae32 20:29:14.505290 PPPoE [ses 0x13] LCP, Prot-Reject (0x08), id 2, length 12 encoded length 10 (=Option(s) length 6) 0x: c021 0802 000a Rejected unknown Protocol (0x8207) Rejected Packet 0x: 0101 0006 20:29:14.505800 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 2, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0102 000a IP-Addr Option (0x03), length 6: 109.71.174.50 0x: 6d47 ae32 20:29:14.506753 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 2, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0202 000a IP-Addr Option (0x03), length 6: 109.71.174.50 0x: 6d47 ae32 20:29:23.247975 PPPoE [ses 0x13] IP (tos 0x0, ttl 255, id 35, offset 0, flags [none], proto ICMP (1), length 100) 109.71.174.50 217.65.161.4: ICMP echo request, id 10, seq 0, length 80 20:29:23.257872 PPPoE [ses 0x13] IP (tos 0x0, ttl 61, id 51771, offset 0, flags [none], proto ICMP (1), length 100) 217.65.161.4 109.71.174.50: ICMP echo reply, id 10, seq 0, length 80 The ping here is the start of real data flowing - I used this setup for about 30 minutes of web browsing with no problems. Paul. ___ 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: Problems with 8.1, PPPoE server, and Cisco client
:38:ca:7a, ethertype PPPoE S (0x8864), length 26: PPPoE [ses 0x21] unknown (0x80fd), length 6: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6 14:59:44.053498 d8:d3:85:c1:5e:ed 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 32: PPPoE [ses 0x21] IPCP (0x8021), length 12: IPCP, Conf-Request (0x01), id 1, length 12 encoded length 10 (=Option(s) length 6) 0x: 8021 0101 000a IP-Addr Option (0x03), length 6: 217.65.168.254 0x: d941 a8fe 14:59:44.059344 54:75:d0:38:ca:7a d8:d3:85:c1:5e:ed, ethertype PPPoE S (0x8864), length 60: PPPoE [ses 0x21] LCP (0xc021), length 6: LCP, Term-Request (0x05), id 2, length 6 14:59:44.059739 d8:d3:85:c1:5e:ed 54:75:d0:38:ca:7a, ethertype PPPoE S (0x8864), length 26: PPPoE [ses 0x21] LCP (0xc021), length 6: LCP, Term-Ack (0x06), id 2, length 6 14:59:44.060925 54:75:d0:38:ca:7a d8:d3:85:c1:5e:ed, ethertype PPPoE D (0x8863), length 60: PPPoE PADT [ses 0x21] 14:59:44.060939 d8:d3:85:c1:5e:ed 54:75:d0:38:ca:7a, ethertype PPPoE D (0x8863), length 38: PPPoE PADT [ses 0x21] [Generic-Error session closed] Many thanks for ideas, suggestions, etc. so far. I'm not well clued up on the inner workings of PPP so any pointers to understand the IPCP or CCP requests that seem to be causing the problem would be welcome. Regards, Paul. ___ 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: ndis: patch for review
On 10/20/10, Bernhard Schmidt bschm...@freebsd.org wrote:
9, 2010 at 23:53, Paul B Mahol one...@gmail.com wrote:
Hi,
First: we should pin curthread on CPU before we check on which CPU is
curthread.
Second: instead of sti cli use critical sections when saving %fs
register.
Third: I do not know what happens if we get preempted while windows
code were running,
so leave critical section only _after_ executing windows code.
Do you have a test case for that? If so, can you post it?
Unfortunately I do not have test case for third problem.
But not using sched_pin or/and critical sections correctly cause
NTOS: timer %p fired even though it was canceled
in my environment - causing watchdog on ndisX.
And attempt to unload miniport driver after that will cause panic
because something got corrupted.
Theoretically when executing windows code there is small chance for
our thread to be preempted and than it will actually cause %fs corruption
on CPU we were running, and reading comments it appears FreeBSD use %fs
for PCPU.
diff --git a/sys/compat/ndis/kern_windrv.c b/sys/compat/ndis/kern_windrv.c
index f231863..ba29fd2 100644
--- a/sys/compat/ndis/kern_windrv.c
+++ b/sys/compat/ndis/kern_windrv.c
@@ -613,8 +613,6 @@ struct gdt {
extern uint16_tx86_getfs(void);
extern void x86_setfs(uint16_t);
extern void *x86_gettid(void);
-extern void x86_critical_enter(void);
-extern void x86_critical_exit(void);
extern void x86_getldt(struct gdt *, uint16_t *);
extern void x86_setldt(struct gdt *, uint16_t);
@@ -668,8 +666,10 @@ extern void x86_setldt(struct gdt *, uint16_t);
void
ctxsw_utow(void)
{
- struct tid *t;
+ struct tid *t;
+ sched_pin();
+ critical_enter();
t = my_tids[curthread-td_oncpu];
/*
@@ -685,12 +685,9 @@ ctxsw_utow(void)
if (t-tid_self != t)
x86_newldt(NULL);
- x86_critical_enter();
t-tid_oldfs = x86_getfs();
t-tid_cpu = curthread-td_oncpu;
- sched_pin();
x86_setfs(SEL_TO_FS(t-tid_selector));
- x86_critical_exit();
/* Now entering Windows land, population: you. */
}
@@ -706,11 +703,10 @@ ctxsw_wtou(void)
{
struct tid *t;
- x86_critical_enter();
t = x86_gettid();
x86_setfs(t-tid_oldfs);
+ critical_exit();
sched_unpin();
- x86_critical_exit();
/* Welcome back to UNIX land, we missed you. */
diff --git a/sys/compat/ndis/winx32_wrap.S b/sys/compat/ndis/winx32_wrap.S
index c051504..fa4aa87 100644
--- a/sys/compat/ndis/winx32_wrap.S
+++ b/sys/compat/ndis/winx32_wrap.S
@@ -375,11 +375,3 @@ ENTRY(x86_setfs)
ENTRY(x86_gettid)
mov %fs:12,%eax
ret
-
-ENTRY(x86_critical_enter)
- cli
- ret
-
-ENTRY(x86_critical_exit)
- sti
- ret
___
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
--
Bernhard
___
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
