RE: PPP routing failure
Check out the install guide at http://www.unixguide.net/freebsd/fbsd_installguide/index.php it has the best step by step instructions for using userppp. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Peter C. Lai Sent: Thursday, March 17, 2005 8:37 PM To: freebsd-questions@freebsd.org; freebsd-net@freebsd.org; freebsd-stable@freebsd.org Subject: PPP routing failure Hi everyone - I'm experiencing some funky routing failures when I dialup netscape internet via user-level PPP: I can negotiate IPCP fine; get a point-to-point link via tun0: myaddr: 172.143.224.146; hisaddr: 63.152.0.70 When the default route is setup to 63.152.0.70, all of my packets are blackholed after the first router hop. I am not using NAT. The PPP link works perfectly fine in windows dialup networking. So I dunno what is wrong. When I look at the routing table in windows, it seems backwards: DESTNM GW IF default 0 myaddr ppp hisaddr 0x myaddr ppp localhost 0xff00 localhost localhost myaddr 0x localhost localhost myaddr.255.255* 0x myaddr ppp multicast multicast myaddr ppp *this is the first 2 dotted quads of myaddr appended with 255.255 If I try to manually set these routes in 5.3-R, I still can't get out :( Setting ADD DEFAULT MYADDR doesn't work, because ppp will still think MYADDR is 0.0.0.0. Either I need sleep or something is funky here... -- Peter C. Lai University of Connecticut Dept. of Molecular and Cell Biology Yale University School of Medicine SenseLab | Research Assistant http://cowbert.2y.net/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Multiple Interfaces
Greets > I have two interfaces and the following info in rc.conf. The > first one is > setup properly but the second one never gets configured. I just went through this process myself. The word I have is that FreeBSD cannot run two NICs on the same subnet, which is what your included config shows. So try as you may it will not work. I also tested 4.7, 5.0 and 5.1 with similar results. Here is a snippet of an email I received on this topic: Begin Well, as long as I can tell, one can't have 2 ifaces on the same subnet on FreeBSD. This seems to be regarded as a feature by the guys who have written the code. "It's arguable that it should be done any other way, since it will put questions like what interface will be used for outgoing segments to the subnet ? etc. which will require to manually assign the arp table as log as you have the rest of the nodes of the subnet connected throu some kind of switches or to still have all outgoing connections throu a preferred interface which will require a SRC (IP+MAC) addresses of the other interface and will unnecessary complicated the hole thing". So the result will be a gain in the speed of incoming segments but more load on the system. END >What am I missing? All you are missing is the fact FreeBSD cannot handle two NICs the same subnet. OpenBSD does, NetBSD does and Linux does. Regards Bob D ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
-current dropping ssh connections
I've got a Pi4 running -current that seems to selectively drop ssh connections. Connections running a shell seem to stay up, but a session running tip to a usb-serial adapter (FTDI TTL232R-3V3) seems go away within a few hours. There don't seem to be any error messages on the console at all, the client session simply reports client_loop: send disconnect: Broken pipe Searches through /var/log/sshd_debug.log find many transactions between the ssh client and the -current target host, but none seem to be error messages; all are either connection reports or disconnects by user. This sort of behavior has been intermittent with aarch64 among both the Pi4 and a pair of Pi3s for some time, but now only the Pi4 is dropping connections. I've tried searching /var/log/sshd_debug.log for the keywords tip, ucom, the IP address of the NAT client used to connect and cuaU0. Are there other things worth looking for? Right now I'm using in /etc/rc.conf the line sshd_flags="-E /var/log/sshd_debug.log" which is already quite verbose. Is there a better option that emphasizes errors over normal traffic? Thanks for reading, bob prohaska
Re: -current dropping ssh connections
On Wed, Jun 21, 2023 at 10:45:25AM -0700, Mark Millard wrote: > On Jun 21, 2023, at 10:24, bob prohaska wrote: > > > I've got a Pi4 running -current that seems to selectively drop ssh > > connections. > > Only when the ssh has text streaming over it? Even when it > is idle? Any other types of context differences that lead > to observable differences of some type related to the > disconnects (vs. lack of them)? I can't detect any consistent pattern. For a while I thought load on the sshd-host end made a difference, but the latest disconnect was on an idle system with serial console output the only traffic on the dropped connection. > > Connections running a shell seem to stay up, but a session running tip to a > > usb-serial adapter (FTDI TTL232R-3V3) seems go away within a few hours. > > The way that reads, ssh to a shell and then running tip in > that shell would stay up. (Does it?) tip is being run > without ssh running a shell? May be more detail about the > two contexts of establishing the connection is needed here? > No, other way 'round. In both cases an ssh connection was made which started a shell. In one a tip session was started, which seems prone to dropping. In the other an active shell (typically running buildworld, or maybe idle) kept running. This makes me think (perhaps wrongly) that tip is involved with the disconnection. Both shells are started as a regular user and then su-d to root. I'm fairly confident this isn't a client-side or NAT problem, simply because there are a dozen or so other ssh sessions running from the ssh client to the various Pi2/3/4 hosts in my collection which stay up basically until they're taken down deliberately. I seem to (vaguely) recall a discussion of ssh problems over NAT some months ago, something about tolerating misssing ts (timestamps?). Is that still possible? Thanks for writing! bob prohaska
Re: -current dropping ssh connections
On Thu, Jun 22, 2023 at 12:05:18AM +0100, Jamie Landeg-Jones wrote: > bob prohaska wrote: > > > I can't detect any consistent pattern. For a while I thought load on the > > sshd-host end made a difference, but the latest disconnect was on an idle > > system with serial console output the only traffic on the dropped > > connection. > > Could it be that the serial connection is sending the ssh-escape sequence? > > Try adding "-e none" to the initial ssh connection command. That seems worth a try. The notion of an ssh escape (~. in this case) finding its way into the data stream is new to me. Since the last reboot to FreeBSD nemesis.zefox.com 14.0-CURRENT FreeBSD 14.0-CURRENT #70 main-476f61217b: Tue Jun 20 16:06:46 PDT 2023 b...@nemesis.zefox.com:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 the ssh-to-tip connection has stayed up with the end running tip unloaded. I'll try adding a load (buildworld) later today to see if that makes a difference. Sometimes stray characters do appear on the tip connection on re-establishment, for example: root@nemesis:/home/bob # tip ucom Stale lock on cuaU0 PID=1238... overriding. connected FreeBSD/arm (ns2.zefox.net) (ttyu0) login: ??? ? ??5)5)???Password: Login incorrect login: The actual display on the ssh client (A Pi4 running RasPiOS) is of charcters resembling a dark question mark in a white oval and small non-Latin characters which apparently can't be copied and pasted. They're less random that what's usually seen with a baud mismatch and at least sometimes (as the example above) seem to get mistaken for a login attempt or command by the serial console process being connected to. This sort of rubbish isn't seen after the connection comes up; it's only found on (re)-connection. Thanks for writing, bob prohaska
Re: -current dropping ssh connections
On Thu, Jun 22, 2023 at 11:38:50PM +0100, Jamie Landeg-Jones wrote: > bob prohaska wrote: > > > That seems worth a try. > > The notion of an ssh escape (~. in this case) finding its way into the data > > stream is new to me. > > Thinking again, that looks like corruption coming down the ssh connection. > For the ssh escape char to affect anything (note it needs to be preceeded > by a new line) it would have to be sent up the line. > > For an example, assuming ssh has the default escape char, look at the > difference between: > > printf 'pwd;\n~.;echo sleeping.; sleep 5' | ssh -tt user@host > > and with the same printf, but no escape char: > > printf 'pwd;\n~.;echo sleeping.; sleep 5' | ssh -tt -e none user@host > > You can see how the former closes the connection due to the \n~. > > (The -tt forces a terminal/interactive session to be set up - normally, as we > are > piping input to ssh in this case, the terminal isnt set up, and the escape > character > isn't used - it's only recongnised in interactive sesions by default) > > I personally have "EscapeChar none" in my ssh_config, but I suspect this > is probably not the issue here, still, can't hurt to try it! Indeed, connection was dropped with escape character set to none. There does seem to be a some dependence on system load. Connections survive at light or no load and drop when the sshd side is busy. Thanks for writing! bob prohaska
Re: -current dropping ssh connections
On Mon, Jun 26, 2023 at 07:38:22PM -0700, Mark Millard wrote: > On Jun 26, 2023, at 19:00, bob prohaska wrote: > > > On Thu, Jun 22, 2023 at 11:38:50PM +0100, Jamie Landeg-Jones wrote: > >> bob prohaska wrote: > >> > >>> That seems worth a try. > >>> The notion of an ssh escape (~. in this case) finding its way into the > >>> data stream is new to me. > >> > >> Thinking again, that looks like corruption coming down the ssh connection. > >> For the ssh escape char to affect anything (note it needs to be preceeded > >> by a new line) it would have to be sent up the line. > >> > >> For an example, assuming ssh has the default escape char, look at the > >> difference between: > >> > >> printf 'pwd;\n~.;echo sleeping.; sleep 5' | ssh -tt user@host > >> > >> and with the same printf, but no escape char: > >> > >> printf 'pwd;\n~.;echo sleeping.; sleep 5' | ssh -tt -e none user@host > >> > >> You can see how the former closes the connection due to the \n~. > >> > >> (The -tt forces a terminal/interactive session to be set up - normally, as > >> we are > >> piping input to ssh in this case, the terminal isnt set up, and the escape > >> character > >> isn't used - it's only recongnised in interactive sesions by default) > >> > >> I personally have "EscapeChar none" in my ssh_config, but I suspect this > >> is probably not the issue here, still, can't hurt to try it! > > > > Indeed, connection was dropped with escape character set to none. > > There does seem to be a some dependence on system load. Connections > > survive at light or no load and drop when the sshd side is busy. > > So how busy is the disk media (really the USB bus) from > somewhat before the failures happen to the failure point? > The question applies separately to both systems involved > in the ssh session. > I've no quantitative measure. Is there any command I could add to the swap activity logger that can report USB load? > I'll remind that on a RPi2B v1.1, RPi2B v1.2, or RPi3B* > the Ethernet and the 4 USB ports all share the one USB2 > path at an internal stage for the USB subsystem, if I > remember right. > > Saturating that USB2 path with data transfer bytes > to/from disk media might be able to block other activity > long enough to cause the Ethernet communications to have > problems for all I know. (Amount of data queued for > transfer would be relevant.) > > This might be a reason to avoid settings for the > combination vm.pfault_oom_attempts and vm.pfault_oom_wait > to values that could contribute to a sustained period of > saturating the USB channel. > At this point the vm.* settings are default, with no warnings on the serial console apparent.. > (I have no detailed knowledge of how the tradeoffs work > for the competing uses of the USB channel. So I can not > validly claim to know that the above is realistic.) > It is tempting to think USB saturation would account for the trouble. A tool similar to gstat, but for USB as a whole, would be helpful if it exists. It's perhaps notable that the dropped connections are seen in connection with usb-serial adapters more than interactive connections running shells. Thanks for reading! bob prohaska
Re: -current dropping ssh connections
On Tue, Jun 27, 2023 at 03:47:26PM +0100, Jamie Landeg-Jones wrote: > bob prohaska wrote: > > > It is tempting to think USB saturation would account > > for the trouble. A tool similar to gstat, but for > > USB as a whole, would be helpful if it exists. > > Would this do? > > /usr/ports/sysutils/usbtop Yes, thank you! bob prohaska
Re: Marvell 88E8057
On 10/23/09, kalin m wrote: > > hi all.. > > does anybody here know if freebsd has a driver for Marvell 88E8057 nic chip? > Marvell provides FreeBSD drivers. If you don't have a philosophical objection to using a manufacturer's binary driver, you might find what you need at their website. http://www.marvell.com/drivers/search.do I think they provide one FreeBSD driver for all of their chipsets. Don't know if it supports the 88E8057. -- -- Bob Johnson fbsdli...@gmail.com ___ 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: Observations from an old timer playing with 64 bit numbers...
On 6/23/10, Randall Stewart wrote: > Then I would strongly suggest you go fix the manual page for ntohl/ > ntohs and > point people to the be64toh() functions... then people would NOT be > ignorant. > > The problem is there is NO clue in the system... Already done, at least in 7.2. But it refers you to them under the alias byteorder(9). - Bob -- -- Bob Johnson fbsdli...@gmail.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 <-> NAT <-> IPv4 ... possible?
On 10/19/07, Marc G. Fournier <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > Could I hide an IPv6 network behind NAT? I don't know if that is even > possible Yes, it is possible. The designers of IPv6 allowed for that configuration as it was expected to be a common one during the transition from IPv4 to IPv6 (i.e. you start using IPv6 but your network is connected to the IPv4 Internet). Although what you end up with might not be exactly what you have in mind: IPv6 can automatically tunnel through an IPv4 NAT, so using that is probably the easiest configuration. In that case, the firewall features of your NAT box (if any) would do nothing for your IPv6 systems - unless it supports IPv6 firewalling as well. In principle at least, with not much effort (heh) your IPv6 boxes could all have public IPv6 addresses even though they are behind your IPv4 NAT box. The other approach would be to have an IPv6 to IPv4 gateway behind your NAT box (or it would actually be your NAT box). > ... the IPv6 IPs would be private (equiv to 192.168.x.x) ... basically, none > of > the hosts behind NAT need a public IP, *but* I may end up with more then 256 > hosts, so was wondering if using IPv6 behind the NAT would be 'simplier' ... It probably will not be "simpler". It will have a fairly steep learning curve, while using IPv4 NAT with more than 256 hosts should be no problem unless your NAT box is artificially limited to that number. E.g. you can have 65K hosts behind your NAT by using 192.168.0.0/16 as your network instead of the common 192.168.0.x/24. If you are using an of-the-shelf home router/firewall, you are probably limited to 253 hosts, but if you are using a FreeBSD box to do NAT, you should be able to have as many hosts has you wish behind it on IPv4. > > If possible, pointers to docs to read would be appreciated ... I wish I had them. You just learned most of what I know about IPv6, but I'm working on improving that. - Bob ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Merging rc.d/network_ipv6 into rc.d/netif
On 11/5/07, Mike Makonnen <[EMAIL PROTECTED]> wrote: > Most IP related knobs will have an ipv4_ and ipv6_ version. To make the > transition easier rc.subr(8) will "automagically" DTRT for the following > knobs: > gateway_enable => ipv4_gateway_enable > router_enable => ipv4_router_enable > router => ipv4_router > router_flags => ipv4_router_flags > defaultrouter => ipv4_defaultrouter > static_routes => ipv4_static_routes > static_routes_ => ipv4_static_routes_ > route_=> ipv4_route_ > dhclient_program => ipv4_dhclient_program > dhclient_flags => ipv4_dhclient_flags > dhclient_flags_ => ipv4_dhclient_flags_ > background_dhclient_ => ipv4_background_dhclient_ > > Please try it and let me know what you think. Personally, I'd prefer the new names be along the lines of ifconfig__ipv4, ifconfig__ipv6, defaultrouter_ipv4, defaultrouter_ipv6, dhclient_program_ipv4, dhclient_program_ipv6, etc. The alphabetical ordering of my rc.conf file will remain more sensible, at least to my mind. All the dhclient knobs would still be grouped together, etc. But separating rc.conf into an ipv4 section and an ipv6 section (which your names would do) is entirely reasonable, so I don't feel strongly about it. And your names would segregate network configuration knobs from all the other things found in rc.conf, which some might view as an advantage. And this would be a good time to change defaultrouter to default_router! - Bob ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SLIP slipping away
On 3/15/08, Kai Lockwood <[EMAIL PROTECTED]> wrote: > I was just trying to setup a really simple network with a null modem cable. > I looked into ppp but the documentation I read didn't help and I'm still not > smart enough to figure out how to do it yet. I haven't ever used SLIP on FreeBSD, but serial port implementations can be extremely picky about the use of RS-232 control signals. If your null modem doesn't at least support DCD you will likely have problems. In that specific case, slattach -l ... might help (that's a lower-case "L"). In fact, for a null modem cable, I'd expect the -l option would be desirable anyway (but as I said, I haven't used SLIP myself, so that's just conjecture). slattach(8) seems to say the default behavior is to abort if there is no reattach script specified (the -r option) unless you specify -l, so it might even fit the symptoms you describe. In other words, try slattach -l -s 115200 /dev/cuad0 and see if that helps. If both systems have Ethernet ports it would be easy (easier, I suspect) to set up a two-node network with a crossover cable, assuming that's a workable solution for you. - Bob ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
portscan looks like.....
Hello- I have just done a portscan on my FreeBSD box running 5.2.1 and got : PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 1023/tcp open netvenuechat now, i made a faux pas when i configured this machine and had made this a nfs client...i belive that was the case. I am now interested in turning this off, and will be able to do that with rpcbind_enable="NO" in rc.conf. Then there is the case of the port 1023. I have no idea how to turn this off or how it got turned on. Could the rpcbind allowed someone into my computer to hack it up? I am pretty scared at this point. Can somone help me? thanks, Bob ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gateway for separate networks
Hello all- I want to install another NIC in my box running 5.2.1 to access another network. Since I have never done this before, I have a question about the gateway that the second NIC will usemore specifically, where do I configure the gateway for the second NIC. I have the defaultrouter in the rc.conf file for the first, do I do the same or do I add routes to tackle this. If someone could show me any resources on the web that deals with this,that would be great. thanks, Bob ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: gateway for separate networks
I should have been more descriptive in describing what I need. I have two networks that are routed to me via a serial connection, namely a T1. I have just installed a new router and it has two ethernet ports that will route to the two different networks. What I want to do is have a single machine have two routes to the Internet, but each NIC going through its respective network...one is a /24 and the other a /28. So, i would think that this would require that "fancier setup", due to the fact that I want traffic going out each nic to go through its networks gateway. Now, what is this fancier setup? /bob At 05:01 PM 9/11/2004 -0700, you wrote: Assuming the second nic is used for it's own private subnet, and not a second route to the internet (which would require a much fancier setup ;-) you don't need to do anything except add the interface, configure it, and adjust any firewall rules to allow whatever access you need. Any services you are running on the box that SPECIFICALLY listen to a certain address may be changed to listen on all addresses or to add this new address if needed. hth. m/ > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Bob Ababurko > Sent: Saturday, September 11, 2004 4:49 PM > To: [EMAIL PROTECTED] > Subject: gateway for separate networks > > > Hello all- > >I want to install another NIC in my box running 5.2.1 to > access another > network. Since I have never done this before, I have a question > about the > gateway that the second NIC will usemore specifically, where do I > configure the gateway for the second NIC. I have the > defaultrouter in the > rc.conf file for the first, do I do the same or do I add routes to tackle > this. If someone could show me any resources on the web that deals with > this,that would be great. > > thanks, > Bob > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gateway for separate networks
At 01:18 AM 9/12/2004 -0400, Charles Swiger wrote: On Sep 11, 2004, at 9:41 PM, Bob Ababurko wrote: I have two networks that are routed to me via a serial connection, namely a T1. I have just installed a new router and it has two ethernet ports that will route to the two different networks. What I want to do is have a single machine have two routes to the Internet, but each NIC going through its respective network...one is a /24 and the other a /28. So, i would think that this would require that "fancier setup", due to the fact that I want traffic going out each nic to go through its networks gateway. Now, what is this fancier setup? Talk to your ISPs about setting up BGP peering. This probably involves getting an ASN from www.arin.net and a portable IP netblock. [ If you don't understand what I just said, ask your ISP. ] -- -Chuck OK, I think that I need to make a few more points to make this clearer..sorry about that. The two networks that I have are from the same ISP. They get routed to me via the T1 and land on my serial port. What I have then are two ethernet ports on my router(for a total of three, counting the serial for the T1 link), which are the gateways for the networks that I want to bring up. Right now I have both of the networks up with machines attached which are passing traffic just fine. What I want to do is use one machine to send and receive packets or traffic with two NICs connected to their respective networks instead of using two separate machines to do the duty. It is a matter of telling the machine what to do with the traffic depending what network the traffic originated from. So, if I want traffic to flow using the second NIC, I need to be able to tell the traffic to go out the second NIC to the gateway for that network. Maybe, this is something that is just not possible, but I don't really see why it would be such a big deal, if traffic from a second NIC can traverse a plain old subnet. I just need to add a gateway to that subnet! Ok, what I ultimately want to be able to do is send and receive email from both networks, as each of these network has a specific duty. I am interested in this to cut down on hardware costs, and have not investigated this at the application level to even be able to say it is possible. What I can do, is run another instance of the MTA if it comes down to it. -Bob ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for networking solution.
Hi, At 13:47 16/06/2005, Marcin Jessa wrote: On Thu, 16 Jun 2005 05:37:18 -0700 Frank Mayhar <[EMAIL PROTECTED]> wrote: > > You want SCPS (the Space Communications Protocols Specification) > software. Briefly, it fakes local TCP on either end while talking its > own protocol over the high-latency link. I don't know if there is any > open-source package available but there are certainly commercial > solutions out there. > -- Correct. That's why I asked about this problem here. I was in doubt something like that existed for FreeBSD. We are willing to pay someone to develop such a solution for FreeBSD. I'd love to get in touch with someone willing to pick up that challenge. If you haven't done so, you might want to look at http://www.scps.org/scps/Reference_S_W/reference_s_w.html and see whether the reference implementation would be available for porting to FreeBSD. -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
> On 24 Oct 2018, at 01:23, Warner Losh wrote: > > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > >> -- Start of PGP signed section. >>> On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote: >>>>> On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < >>>>> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: >>>>> >>>>>>> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: >>>>>>>>> I'd also suggest that rl stands in stark contrast to the cs, >> wb, sn, >>>>>> smc, >>>>>>>>> sf, tl, tx and vr drivers, which nobody has mentioned in this >>>>>> thread, and >>>>>>>>> which I doubt are in use in any FreeBSD system of any age >> today. >>>>>>>> >>>>>>>> vr is used by my TV driver laptop: >>>>>>>> http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ >>>>>>>> vr0: flags=8843 metric >> 0 mtu >>>>>> 1500 >>>>>>>>options=82808 >>>>>>>>ether 00:40:d0:5e:26:38 >>>>>>>>inet 192.168.91.65 netmask 0xff00 broadcast >> 192.168.91.255 >>>>>>>>media: Ethernet autoselect (100baseTX >>>>>> ) >>>>>>>>status: active >>>>>>>> >>>>>>>> Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade >> soon >>>>>>>> when I also configure it to receive from a raspberry-pi TV VPN >> server. >>>>>>> >>>>>>> The above was a typo. vr is on the the STAY list. >>>>>>> >>>>>>> -- Brooks >>>>>> Brooks, >>>>>>Is there a public revised version of FCP-0101 that >> reflects the >>>>>> feedback which is what core is voting on? >>>>>> >>>>> >>>>> Its on github, just like it's been the whole time for anybody to see, >>>>> submit pull requests against and track: >>>> >>>> I have no gh account, desires no gh account, so have no way to >>>> submit a change request other than through direct email to >>>> brooks or another gh user. This is fundementally flawed. >>>> >>>>> https://github.com/freebsd/fcp/blob/master/fcp-0101.md >>>> >>>> Thank you for the link, I had looked at it before MeetBSD, >>>> which did not have most of the recent changes done "a day ago". >>>> >>>> Isnt this document now in a frozen state while core reviews/votes? >>> >>> I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only >>> to notice a bug in table rendering. I submitted a pull request fix >>> that and a missing word which was merged since neither was material. I >>> suppose they could have waited or been skipped, but there's no value in >>> the FCP process being bound by the sort of pointless rigidity that led >>> to -DPOSIX_MISTAKE in every libc compile line. >> >> The FCP process itself is unclear on this point, >> I think this should be clarified. >> >> It is much more clear on post approval: >>Changes after acceptance >> >>FCPs may need revision after they have been moved into the >>accepted state. In such cases, the author SHOULD update the >>FCP to reflect the final conclusions. >>If the changes are major, the FCP SHOULD be withdrawn >>and restarted. >> > > Good point Rod. While common sense suggests that trivial changes during the > voting should be allowed for editorial purposes (eg fix grammar mistakes, > table rendering etc), it's better to spell that out so there's no confusion. > > diff --git a/fcp-.md b/fcp-.md > index b4fe0f3..c8cc6f7 100644 > --- a/fcp-.md > +++ b/fcp-.md > @@ -144,7 +144,10 @@ When the discussion of a change has come to a suitable > and acceptable close it > SHOULD be updated to the `vote` state. > > At this time the FreeBSD Core Team will vote on the subject of the FCP. The > -result of vote moves the FCP into the `accepted` or `rejected` state. > +result of vote moves the FCP into the `accepted` or `rejected` state. The > +core team MAY make minor edits to the FCP
Re: Impending NATM removal
Hi, > On 7 Apr 2017, at 00:57, Brooks Davis wrote: > > As previously threatened, I plan to remove NATM support next week. This > includes the drivers en(4), fatm(4), hatm(4), and patm(4). None of > these devices have been manufactured in the last 20 years so it is time > to move on. I don’t have a dog in this fight, but for instance ProSum PROATM-E155 (patm(4)) still appear to be available. See http://www.prosum.net/en/products/atm-adapters > The planned commit can be seen at https://reviews.freebsd.org/D9883 > > -- Brooks -- Bob Bishop r...@gid.co.uk ___ 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"
Erratic ping behavior, was Re: Pi3 answers ssh only if outbound ping is running on -current
[changed subject to more clearly reflect the symptoms] On Mon, Feb 14, 2022 at 09:59:23PM -0800, Mark Millard wrote: > >>>> Since I have a context working based on the kernel in: > >>>> > >>>> https://artifact.ci.freebsd.org/snapshot/stable-13/371633ece3ae88e3b3d7a028c372d4ac4f72b503/arm64/aarch64/kernel.txz > >>>> > >>>> I recommend that you try that exact same kernel in your > >>>> stable/13 context. I recommend renaming the existing > >>>> /boot/kernel before expanding the kernel.txz into / and > >>>> so causing a new /boot/kernel/ to be filled in. > It looks like the kernel isn't an obvious culprit: Versions from late October to a few days ago all behave the same way. Even when booted single-user, with the ue0 device brought up by hand, only about 1% of incoming pings are answered. That figure rises to a little over 50% when there's an outgoing ping process (both running a 1/seccond). Destination of the ping does not seem to matter, an unused IP seems to work fine. AIUI, nothing of userland apart from a shell and the ping process will be running under those circumstances. Is this correct? Might the trouble be inherited from the boot files? I've left them alone since the machine does boot and updating them isn't automated. Right now the machine boots from microSD and then runs bootcmd_usb0. One oddity noticed during the kernel-swapping experiments is that at the loader prompt some kernel names don't seem to be recognized. If I type kernel or kernel.old it's loaded immediately. If I type kernel.no-bpf which is one I built, booted using the name kernel and then saved with the name kernel.no-bpf it can't be found, even though it's visible via ls at the OK prompt. Might - be a prohibited or priviledged character to the loader? Names like kernel.20220214 are likewise not recognized, even though they're visible using ls. For lack of immediately better ideas I've started stress2 running in single-user mode to see if anything of interest results. Thanks for reading, and any ideas! bob prohaska
Re: Erratic ping behavior, was Re: Pi3 answers ssh only if outbound ping is running on -current
It looks as if things are somewhat altered, but not really improved, after updating to FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #24 stable/13-n249989-b85d0d603c5: Sat Mar 12 17:47:19 PST 2022 b...@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 on the Pi3 with USB root disk (hdd, not ssd). After reboot the machine answered around 30 % of incoming pings and sometimes responded to ssh login attempts. At least once the login attempt was successful, even with no outgoing ping process running. That seems like progress. With an outgoing ping running it's possible to ssh into the machine, with a highly variable delay for the password prompt. Unfortunately, new console errors are appeared: bob@pelorus:~ % (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 1f ea a3 c0 00 00 40 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) (da0:umass-sim0:0:0:0): Retrying command (per sense data) The error message repeated at intervals, seemingly linked to disk activity, with the machine running out of retries after starting buildworld. That seems like progress in reverse 8-) Reverting to 13-n249985-dd6c1475a63: Fri Mar 11 18:06:31 PST 2022 permitted recovery, with the old problems attendant. -current now has some usb testing tools: root@www:/usr/src # ls tools/tools/usbtest Makefileusb_control_ep_test.c usb_msc_test.c usbtest.c Makefile.depend usb_modem_test.cusb_msc_test.h usbtest.h Is there any guidance on what they do? I couldn't find a man page. Thanks for reading, bob prohaska
Re: 60+% ping packet loss on Pi3 under -current and stable-13
Since about December of 2021 I've been noticing problems with wired network connectivity on a pair of raspberry pi 3 machines using wired network connections. One runs stable-13.1, the other runs -current, both are up to date as of a few days ago. Essentially both machines fail to respond to inbound network connections via ssh or ping after reboot. If I get on the serial console and start an outbound ping to anywhere, both machines respond to incoming pings with about a 65% packet loss. Ssh connections are answered with delays of zero to perhaps thirty seconds. Once connected ssh is usable but erratic, with dropped characters, multi-second delays and disconnects after random intervals from minutes to hours. There are five other Raspberry Pi's on the network. Three Pi2's run 12.3-stable, one Pi2 runs -current and a Pi4 runs -current. All have no problems pinging one another and out of network, so there's nothing obviously wrong with the net. The network is not routed, but rather a block of eight addresses simply bridged from my ISP over DSL. It's been found that an image of 13.1-RC4 behaves similarly on one Pi3 when on the public network but exhibits more normal ping response when moved to a 192.168.1.n private network. On the face of it, this seems significant, but I can't guess how. I recall a post on one of the mailing lists about a bug that caused problems when packets arrived out-of-order via NAT, but I'm using direct same-network pings and pinging through NAT seems little-to-no worse. I was hoping to upgrade my stable-12 machines to stable-13, but seeing this behavior gives me pause. If anyone can suggest tests or experiments to figure out what's going on I'd be most grateful. I'm no programmer but can follow simple instructions. If this sounds like a known bug(s) links to bugzilla would be of much interest. Many thanks for reading, and any ideas! If some essential details have been omitted please indicate and I'll try to supply them. bob prohaska
Re: 60+% ping packet loss on Pi3 under -current and stable-13
On Fri, Apr 29, 2022 at 08:14:27PM -0700, Mark Millard wrote: > On 2022-Apr-29, at 19:12, bob prohaska wrote: > > > Since about December of 2021 I've been noticing problems with > > wired network connectivity on a pair of raspberry pi 3 machines > > using wired network connections. One runs stable-13.1, the other > > runs -current, both are up to date as of a few days ago. > > Compared to your later notes about 192.168.1.n style use, > are any of the above that way? Or are the all well-analogous > to the "on the public network" context mentioned later? > Not sure I follow what you're getting at, could you clarify please? The move between public and private networks was done by changing comment delimiters in /etc/rc.conf and moving cables between public switch and private router. Only the two Pi3s have so far failed to answer pings and ssh connections after reboot. > > Essentially both machines fail to respond to inbound network > > connections via ssh or ping after reboot. If I get on the > > serial console and start an outbound ping to anywhere, both > > machines respond to incoming pings with about a 65% packet > > loss. Ssh connections are answered with delays of zero to > > perhaps thirty seconds. Once connected ssh is usable but > > erratic, with dropped characters, multi-second delays and > > disconnects after random intervals from minutes to hours. > > > > There are five other Raspberry Pi's on the network. Three > > Pi2's run 12.3-stable, one Pi2 runs -current > > RPi2 v1.2's used as aarch64? (So similar to RPi3*'s.) No, the Pi2s are v1.1. > RPi2 v1.1's (armv7)? Yes. > Which type of RPi3* variant? B? B+? Revision? > The stable/13 machine reports: bob@pelorus:~ % sysctl -a | grep model hw.model: ARM Cortex-A53 r0p4 hw.fdt.compatible: raspberrypi,3-model-b brcm,bcm2837 hw.fdt.model: Raspberry Pi 3 Model B Rev 1.2 dev.smscphy.0.%pnpinfo: oui=0x800f model=0xc rev=0x3 bob@pelorus:~ % and the -current machine reports: bob@www:~ % sysctl -a | grep -i model Memory Model Features 0 = Memory Model Features 1 = <8bit VMID> Memory Model Features 2 = <32bit CCIDX,48bit VA> hw.model: ARM Cortex-A53 r0p4 hw.fdt.compatible: raspberrypi,3-model-b brcm,bcm2837 hw.fdt.model: Raspberry Pi 3 Model B Rev 1.2 dev.smscphy.0.%pnpinfo: oui=0x800f model=0xc rev=0x3 bob@www:~ % That's slightly surprising, since they are of different age and one has WiFi, not sure which. I believe that makes one a B+ though I gather FreeBSD still doesn't support the on-board WiFi. Either way, I thought the wired ethernet setup was identical. > > and a Pi4 runs > > -current. All have no problems pinging one another and out > > of network, so there's nothing obviously wrong with the net. > > The network is not routed, but rather a block of eight > > addresses simply bridged from my ISP over DSL. > > > > It's been found that an image of 13.1-RC4 behaves similarly > > on one Pi3 when on the public network but exhibits more normal > > ping response when moved to a 192.168.1.n private network. Just to be clear, it was the same Pi3, I moved the cables and changed lines in /etc/rc.conf to make the switch. > > On the face of it, this seems significant, but I can't guess how. > > Did you try a RPi4B on the public network, booted using the > same 13.1-RC4 microsd card you used in the RPi3* testing? > (Modern aarch64 RPi* images should boot either type of > aarch64 RPI*.) > > If yes, what was the behavior like? Did it behave like the > RPi3*? > > If no, it should be a good test for how specific the problem > is to the RPi3* vs. RPi*'s more generally. > I haven't tried yet, since the Pi4 was on the private network to begin with and it has never had problems answering ping and ssh. AIUI the Pi4 ethernet is on PCIe, while the Pi3 uses USB. If the Pi4 failed to answer ping when running the snapshot I guess that would point to either faulty media or a different place in the network software. Perhaps worth a try. > Testing a EtherNet dongle known to use a different driver > could also be a form of cross check, if you happen to have > such available. My only alternative Ethernet adapter is a Ralink WiFi dongle. My WiFi is private-network only, and the snapshot worked reasonably well when wired on the private network. A wired adapter would be more informative, but I'll have to figure out what to order. Thanks for writing! bob prohaska
Re: 60+% ping packet loss on Pi3 under -current and stable-13
On Sat, Apr 30, 2022 at 06:39:57PM -0700, Bakul Shah wrote: > On Apr 29, 2022, at 7:12 PM, bob prohaska wrote: > > > > Since about December of 2021 I've been noticing problems with > > wired network connectivity on a pair of raspberry pi 3 machines > > using wired network connections. One runs stable-13.1, the other > > runs -current, both are up to date as of a few days ago. > > > > Essentially both machines fail to respond to inbound network > > connections via ssh or ping after reboot. If I get on the > > serial console and start an outbound ping to anywhere, both > > machines respond to incoming pings with about a 65% packet > > loss. > Suggest running tcpdump on the rpi3 to see what is going on > when connected to the public vs private net. > Public net first, since that's where the machine is now. Gateway.zefox.net is the name of my router's public interface, dcn.org belongs to my isp and fusionbroadband is their service provider.. While on the -current Pi3 serial console (with no outbound ping running) and no inbound traffic from my hosts I see after a couple minutes: root@www:/mnt # tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ue0, link-type EN10MB (Ethernet), capture size 262144 bytes 10:39:40.887853 ARP, Request who-has www.zefox.org tell gateway.zefox.net, length 46 10:39:40.887929 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui Unknown), length 28 10:39:40.893220 ARP, Request who-has 50-1-20-1.dsl.static.fusionbroadband.com tell www.zefox.org, length 28 10:39:40.915469 ARP, Reply 50-1-20-1.dsl.static.fusionbroadband.com is-at 00:1b:90:d2:4a:c4 (oui Unknown), length 50 10:39:40.915529 IP www.zefox.org.50714 > spoke.dcn.davis.ca.us.domain: 51409+ PTR? 28.20.1.50.in-addr.arpa. (41) 10:39:40.943602 IP spoke.dcn.davis.ca.us.domain > www.zefox.org.50714: 51409 1/3/6 PTR www.zefox.org. (265) 10:39:40.945416 IP www.zefox.org.15986 > spoke.dcn.davis.ca.us.domain: 44966+ PTR? 31.20.1.50.in-addr.arpa. (41) 10:39:40.973487 IP spoke.dcn.davis.ca.us.domain > www.zefox.org.15986: 44966 1/3/6 PTR gateway.zefox.net. (266) 10:39:40.975037 IP www.zefox.org.57611 > spoke.dcn.davis.ca.us.domain: 31749+ PTR? 1.20.1.50.in-addr.arpa. (40) 10:39:46.288219 IP www.zefox.org.49710 > wheel.dcn.davis.ca.us.domain: 31749+ PTR? 1.20.1.50.in-addr.arpa. (40) 10:39:46.316239 IP wheel.dcn.davis.ca.us.domain > www.zefox.org.49710: 31749 1/3/6 PTR 50-1-20-1.dsl.static.fusionbroadband.com. (291) 10:39:46.318267 IP www.zefox.org.17061 > spoke.dcn.davis.ca.us.domain: 37579+ PTR? 2.253.150.168.in-addr.arpa. (44) 10:39:46.346851 IP spoke.dcn.davis.ca.us.domain > www.zefox.org.17061: 37579* 1/2/2 PTR spoke.dcn.davis.ca.us. (145) 10:39:46.348674 IP www.zefox.org.40440 > spoke.dcn.davis.ca.us.domain: 20572+ PTR? 1.253.150.168.in-addr.arpa. (44) 10:39:51.420705 IP www.zefox.org.64019 > wheel.dcn.davis.ca.us.domain: 20572+ PTR? 1.253.150.168.in-addr.arpa. (44) 10:39:51.448850 IP wheel.dcn.davis.ca.us.domain > www.zefox.org.64019: 20572* 1/2/2 PTR wheel.dcn.davis.ca.us. (145) 10:40:40.147603 ARP, Request who-has 50-1-20-1.dsl.static.fusionbroadband.com tell ns1.zefox.net, length 46 10:40:40.148844 IP www.zefox.org.46127 > spoke.dcn.davis.ca.us.domain: 12186+ PTR? 29.20.1.50.in-addr.arpa. (41) 10:40:40.176486 IP spoke.dcn.davis.ca.us.domain > www.zefox.org.46127: 12186 1/3/6 PTR ns1.zefox.net. (262) 10:40:57.688225 ARP, Request who-has www.zefox.org tell gateway.zefox.net, length 46 10:40:57.688305 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui Unknown), length 28 10:42:14.488727 ARP, Request who-has www.zefox.org tell gateway.zefox.net, length 46 10:42:14.488804 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui Unknown), length 28 10:42:43.761226 ARP, Request who-has 50-1-20-1.dsl.static.fusionbroadband.com tell www.zefox.com, length 46 10:42:43.762522 IP www.zefox.org.56181 > spoke.dcn.davis.ca.us.domain: 28779+ PTR? 26.20.1.50.in-addr.arpa. (41) 10:42:43.790361 IP spoke.dcn.davis.ca.us.domain > www.zefox.org.56181: 28779 1/3/6 PTR www.zefox.com. (265) 10:43:31.289103 ARP, Request who-has www.zefox.org tell gateway.zefox.net, length 46 10:43:31.289181 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui Unknown), length 28 If I now start an inbound ping from one of my hosts it gets no reply and tcpdump reports no additional traffic. With an outbound ping running there's at least a sparse reply. ^C 28 packets captured 28 packets received by filter 0 packets dropped by kernel root@www:/mnt # The "oui unknown" looks like some sort of failure. Can you ping www.zefox.org? I have no outside vantage point. There is still no outbound ping running and I would expect you'll get no or very sparse reply. Thus far only the two Pi3s suffer from connectivity problems; Pi2s and
Re: 60+% ping packet loss on Pi3 under -current and stable-13
On Sun, May 01, 2022 at 12:58:45PM -0700, Mark Millard wrote: > > Looks like there is some problem getting past > gig1-1-1.gw.davsca11.sonic.net . > That seems independent of my own internal connection problems, but worth taking up with my ISP on Monday. Meanwhile, can you ping any other hosts in the 50.1.20.31-24 range? All are up at the moment. Hosts 28 and 24 are the troublemakers. If anybody cares there's an ascii-art network diagram at http://www.zefox.net/~fbsd/netmap Not sure it'll survive the mailing list, but here goes: dsl_modem-switch-router-lan---wifi-pi4_workstation | | | | | |---Mac workstation | | | |--printer --| | |--50.1.20.30 ns1.zefox.net Pi2 12.3 usb-serial50.1.20.27 |--50.1.20.29 ns2.zefox.net Pi2 12.3 usb-serial50.1.20.30 |--50.1.20.27 www.zefox.net Pi2 12.3 usb-serial50.1.20.26 |--50.1.20.26 www.zefox.com Pi2 -current usb-serial---50.1.20.24 |--50.1.20.24 pelorus.zefox.org Pi3 13.1 usb-serial---50.1.20.28 switch |--50.1.20.25 nemesis.zefox.com Pi4 -current usb-serial---50.1.20.29 |--50.1.20.28 www.zefox.org Pi3 -current usb-serial50.1.20.25 Thanks for your help! bob prohaska
Re: 60+% ping packet loss on Pi3 under -current and stable-13
On Sun, May 01, 2022 at 05:10:59PM -0700, Mark Millard wrote: [reply at end] > On 2022-May-1, at 16:27, bob prohaska wrote: > > > On Sun, May 01, 2022 at 12:58:45PM -0700, Mark Millard wrote: > >> > >> Looks like there is some problem getting past > >> gig1-1-1.gw.davsca11.sonic.net . > >> > > > > That seems independent of my own internal connection problems, > > but worth taking up with my ISP on Monday. Meanwhile, can you > > ping any other hosts in the 50.1.20.31-24 range? All are up > > at the moment. Hosts 28 and 24 are the troublemakers. > > > > If anybody cares there's an ascii-art network diagram at > > http://www.zefox.net/~fbsd/netmap > > > > Not sure it'll survive the mailing list, but here goes: > > dsl_modem-switch-router-lan---wifi-pi4_workstation > > | | | > > | | |---Mac workstation > > | | > > | |--printer > >--| > >| > >|--50.1.20.30 ns1.zefox.net Pi2 12.3 usb-serial50.1.20.27 > >|--50.1.20.29 ns2.zefox.net Pi2 12.3 usb-serial50.1.20.30 > >|--50.1.20.27 www.zefox.net Pi2 12.3 usb-serial50.1.20.26 > >|--50.1.20.26 www.zefox.com Pi2 -current usb-serial---50.1.20.24 > >|--50.1.20.24 pelorus.zefox.org Pi3 13.1 usb-serial---50.1.20.28 > > switch > >|--50.1.20.25 nemesis.zefox.com Pi4 -current usb-serial---50.1.20.29 > >|--50.1.20.28 www.zefox.org Pi3 -current usb-serial50.1.20.25 > > > For ns1.zefox.net there is no problem and > it looks like: > > My traceroute [v0.95] > amd64_ZFS (192.168.1.120) -> ns1.zefox.net (50.1.20.29) > 2022-05-01T16:52:27-0700 > Keys: Help Display mode Restart statistics Order of fields quit >Packets > Pings > HostLoss% Snt Last Avg > Best Wrst StDev > 1. 192.168.1.1 0.0%531.2 0.8 > 0.1 1.4 0.4 > 2. 172.30.26.67 0.0%53 11.8 25.0 > 11.8 61.0 11.4 > 3. 68.85.243.125 0.0%53 10.0 10.0 > 7.7 46.9 5.3 > 4. 96.216.60.165 0.0%538.8 9.3 > 7.8 12.1 0.9 > 5. 68.85.243.197 0.0%538.6 13.2 > 8.6 28.3 4.2 > 6. be-36231-cs03.seattle.wa.ibone.comcast.net0.0%53 15.3 14.8 > 13.0 16.9 1.0 > 7. be-2312-pe12.seattle.wa.ibone.comcast.net 0.0%53 16.2 15.9 > 12.9 59.8 6.5 > 8. (waiting for reply) > 9. be3717.ccr22.sfo01.atlas.cogentco.com 0.0%53 29.8 30.9 > 26.5 97.9 10.1 > 10. be2430.ccr31.sjc04.atlas.cogentco.com 0.0%53 29.0 29.0 > 26.6 39.3 1.8 > 11. 38.104.141.82 0.0%53 28.9 33.8 > 26.1 115.0 17.0 > 12. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net0.0%53 32.1 31.3 > 29.2 33.9 1.0 > 13. 0.xe-0-0-0.cr1.scrmca13.sonic.net 0.0%53 30.5 32.1 > 29.2 57.6 4.3 > 14. gig1-1-1.gw.wscrca11.sonic.net0.0%53 31.8 32.0 > 28.8 43.7 2.0 > 15. gig1-1-1.gw.davsca11.sonic.net0.0%52 31.0 32.4 > 30.2 38.4 1.4 > 16. ns1.zefox.net 0.0%52 51.4 51.1 > 49.8 53.4 0.8 > > ns2.zefox.net and others got a 17. instead of > a 16. An example is: > > My traceroute [v0.95] > amd64_ZFS (192.168.1.120) -> ns2.zefox.net (50.1.20.30) > 2022-05-01T16:58:45-0700 > Keys: Help Display mode Restart statistics Order of fields quit >Packets > Pings > HostLoss% Snt Last Avg > Best Wrst StDev > 1. 192.168.1.1 0.0%550.3 0.9 > 0.1 1.4 0.4 > 2. 172.30.26.66 0.0%55 13.5 26.4 > 10.4 54.7 10.1 > 3. 68.85.243.77 0.0%55 10.5 9.1 > 7.9 10.5 0.6 > 4. 24.124.129.1060.0%548.3 9.5 > 8.2 13.4 1.0 > 5. 96.216.60.165
Re: 60+% ping packet loss on Pi3 under -current and stable-13
On Mon, May 02, 2022 at 08:56:12AM +0200, Hans Petter Selasky wrote: [reply at end] > On 5/2/22 03:13, bob prohaska wrote: > > On Sun, May 01, 2022 at 05:10:59PM -0700, Mark Millard wrote: > > [reply at end] > > > On 2022-May-1, at 16:27, bob prohaska wrote: > > > > > > > On Sun, May 01, 2022 at 12:58:45PM -0700, Mark Millard wrote: > > > > > > > > > > Looks like there is some problem getting past > > > > > gig1-1-1.gw.davsca11.sonic.net . > > > > > > > > > > > > > That seems independent of my own internal connection problems, > > > > but worth taking up with my ISP on Monday. Meanwhile, can you > > > > ping any other hosts in the 50.1.20.31-24 range? All are up > > > > at the moment. Hosts 28 and 24 are the troublemakers. > > > > > > > > If anybody cares there's an ascii-art network diagram at > > > > http://www.zefox.net/~fbsd/netmap > > > > > > > > Not sure it'll survive the mailing list, but here goes: > > > > dsl_modem-switch-router-lan---wifi-pi4_workstation > > > > | | | > > > > | | |---Mac > > > > workstation > > > > | | > > > > | |--printer > > > > --| > > > > | > > > > |--50.1.20.30 ns1.zefox.net Pi2 12.3 usb-serial50.1.20.27 > > > > |--50.1.20.29 ns2.zefox.net Pi2 12.3 usb-serial50.1.20.30 > > > > |--50.1.20.27 www.zefox.net Pi2 12.3 usb-serial50.1.20.26 > > > > |--50.1.20.26 www.zefox.com Pi2 -current usb-serial---50.1.20.24 > > > > |--50.1.20.24 pelorus.zefox.org Pi3 13.1 usb-serial---50.1.20.28 > > > > switch > > > > |--50.1.20.25 nemesis.zefox.com Pi4 -current > > > > usb-serial---50.1.20.29 > > > > |--50.1.20.28 www.zefox.org Pi3 -current > > > > usb-serial50.1.20.25 > > > > > > > > > For ns1.zefox.net there is no problem and > > > it looks like: > > > > > > My traceroute [v0.95] > > > amd64_ZFS (192.168.1.120) -> ns1.zefox.net (50.1.20.29) > > > 2022-05-01T16:52:27-0700 > > > Keys: Help Display mode Restart statistics Order of fields quit > > > Packets > > > Pings > > > HostLoss% Snt Last > > > Avg Best Wrst StDev > > > 1. 192.168.1.1 0.0%531.2 > > > 0.8 0.1 1.4 0.4 > > > 2. 172.30.26.67 0.0%53 11.8 > > > 25.0 11.8 61.0 11.4 > > > 3. 68.85.243.125 0.0%53 10.0 > > > 10.0 7.7 46.9 5.3 > > > 4. 96.216.60.165 0.0%538.8 > > > 9.3 7.8 12.1 0.9 > > > 5. 68.85.243.197 0.0%538.6 > > > 13.2 8.6 28.3 4.2 > > > 6. be-36231-cs03.seattle.wa.ibone.comcast.net0.0%53 15.3 > > > 14.8 13.0 16.9 1.0 > > > 7. be-2312-pe12.seattle.wa.ibone.comcast.net 0.0%53 16.2 > > > 15.9 12.9 59.8 6.5 > > > 8. (waiting for reply) > > > 9. be3717.ccr22.sfo01.atlas.cogentco.com 0.0%53 29.8 > > > 30.9 26.5 97.9 10.1 > > > 10. be2430.ccr31.sjc04.atlas.cogentco.com 0.0%53 29.0 > > > 29.0 26.6 39.3 1.8 > > > 11. 38.104.141.82 0.0%53 28.9 > > > 33.8 26.1 115.0 17.0 > > > 12. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net0.0%53 32.1 > > > 31.3 29.2 33.9 1.0 > > > 13. 0.xe-0-0-0.cr1.scrmca13.sonic.net 0.0%53 30.5 > > > 32.1 29.2 57.6 4.3 > > > 14. gig1-1-1.gw.wscrca11.sonic.net0.0%53 31.8 > > > 32.0 28.8 43.7 2.0 > > > 15. gig1-1-1.gw.davsca11.sonic.net0.0%52 31.0 > > > 32.4 30.2 38.4 1.4 > > > 16. ns1.zefox.net 0.0%52 51.4 > > > 51.1 49.8 53.4
Re: 60+% ping packet loss on Pi3 under -current and stable-13
On Mon, May 02, 2022 at 06:48:58PM +0200, Hans Petter Selasky wrote:
>
> You may also want to correlate:
>
> usbconfig dump_stats
>
On the -current Pi3 I see in part:
ugen1.4: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
(500mA)
{
UE_CONTROL_OK : 83
UE_ISOCHRONOUS_OK : 0
UE_BULK_OK : 3730195
UE_INTERRUPT_OK : 0
UE_CONTROL_FAIL : 0
UE_ISOCHRONOUS_FAIL : 0
UE_BULK_FAIL: 61
UE_INTERRUPT_FAIL : 0
}
That's the USB3 hard disk boot drive. All other devices report zero bulk fails.
> with netstat for ue0 .
>
On the same machine one gets:
root@www:/home/bob # netstat -i -n ue0
NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs
Coll
lo0 16384 lo0185 0 0 185 0
0
lo0 - ::1/128 ::1 0 - -0 -
-
lo0 - fe80::%lo0/64 fe80::1%lo0 0 - -0 -
-
lo0 - 127.0.0.0/8 127.0.0.1 185 - - 185 -
-
ue01500 b8:27:eb:71:46:4e 244278 0 0 213240 0
0
ue0 - 50.1.20.0/24 50.1.20.28 213957 - - 210970 -
-
root@www:/home/bob #
Nothing obviously amissif I'm looking at the right data.
> Especially the BULK column. If something is wrong on the USB level, it will
> show up there.
>
On a whim, I checked a Pi4 running -current which also has a usb-sata boot
drive.
It reports UE_BULK_FAIL: 56 for the disk and performance seems good.
An old Pi2 running -current with a relatively old USB2-sata boot disk
reports zero bulk errors. No bulk errors seems desirable, but is some
non-zero error rate normal?
All three machines have been updated within a couple of days.
Thanks for writing!
bob prohaska
Re: 60+% ping packet loss on Pi3 under -current and stable-13
On Mon, May 02, 2022 at 11:45:21AM -0700, Mark Millard wrote: > I just saw something odd when trying to test again. > > I did not manage to capture the earlier display updates > but when it first connected it had a list of "(waiting > for reply)" lines from 17. to 27. with www.zefox.org > at 28. That range got shorter in steps but fairly > rapidly. Before the 18. to 28. showed up it sat at > 17. (waiting for reply) for a while. > > I finally captured it with www.zefox.org at 20. : > > My traceroute [v0.95] > amd64_ZFS (192.168.1.120) -> www.zefox.org (50.1.20.28) > 2022-05-02T11:36:06-0700 > Keys: Help Display mode Restart statistics Order of fields quit >Packets > Pings > HostLoss% Snt Last Avg > Best Wrst StDev > 1. 192.168.1.1 0.0%300.2 0.8 > 0.2 1.5 0.4 > 2. 172.30.26.66 0.0%30 69.5 70.0 > 42.1 138.0 19.7 > 3. 68.85.243.77 0.0%30 38.8 49.3 > 38.8 61.5 6.7 > 4. 24.124.129.1060.0%30 64.0 52.2 > 10.1 109.4 14.7 > 5. 96.216.60.165 0.0%30 62.6 47.6 > 17.3 62.6 12.0 > 6. 68.85.243.197 0.0%29 66.9 55.0 > 28.4 78.3 10.5 > 7. be-36241-cs04.seattle.wa.ibone.comcast.net0.0%29 68.9 57.8 > 28.6 122.3 14.9 > 8. be-2412-pe12.seattle.wa.ibone.comcast.net 0.0%29 65.7 57.8 > 49.5 120.7 13.5 > 9. (waiting for reply) > 10. be2075.ccr21.sfo01.atlas.cogentco.com 0.0%29 78.6 74.3 > 63.7 135.2 15.4 > 11. be2379.ccr31.sjc04.atlas.cogentco.com 0.0%29 83.0 74.0 > 62.1 153.8 20.6 > 12. 38.104.141.82 0.0%29 106.6 78.3 > 62.0 168.3 25.7 > 13. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net0.0%29 83.7 73.4 > 58.9 134.8 13.5 > 14. 0.xe-0-0-0.cr1.scrmca13.sonic.net 0.0%29 60.6 72.0 > 50.8 135.6 14.3 > 15. gig1-1-1.gw.wscrca11.sonic.net0.0%29 104.8 75.1 > 44.2 136.7 18.8 > 16. gig1-1-1.gw.davsca11.sonic.net0.0%29 85.4 73.8 > 48.2 136.3 14.4 > 17. (waiting for reply) > 18. (waiting for reply) > 19. (waiting for reply) > 20. www.zefox.org86.2%29 160.4 144.9 > 102.1 160.5 28.6 > > www.zefox.org ended up at 17. and stayed there > once it got there. > > I've no clue if this observation is of any use. > It's consistent with my observations of keyboard interaction vis ssh. Input sometimes stop echoing for tens of seconds, then all goes through after the pause. Maybe this really has little or nothing to do with the network, it's just that all my interaction with the two machines is via the network. Neither has had a console and keyboard since I got the Pi4. Thanks for bringing your observations to the discussion! bob prohaska
Re: 60+% ping packet loss on Pi3 under -current and stable-13
After updating one of the troublesome Pi3s to
FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #53
stable/13-n250662-0625715977d: Wed May 4 06:23:14 PDT 2022
b...@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
a series of error messages appeared on the serial console. I've not seen them
before
and wonder if they might be relevant to the connectivity problems lately seen.
The
machine was freshly-rebooted and at the time would not answer ping, though it
did
successfully set time using ntp. I got on the console to start an outbound ping,
which usually sufficed to let inbound ssh connections work. Here's the console:
Starting background file system checks in 60 seconds.
Wed May 4 08:10:53 PDT
FreeBSD/arm64 (pelorus.zefox.org) (ttyu0)
login: bob
Password:
Last login: Tue May 3 09:01:03 from gateway.zefox.net
FreeBSD 13.1-STABLE #53 stable/13-n250662-0625715977d: Wed May 4 06:23:14 PDT
2022 b...@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
[message of the day omitted]
bob@pelorus:~ % ping 50.1.20.31 > ping.log &
[1] 937
bob@pelorus:~ % May 4 08:12:19 pelorus su[952]: bob to root on /dev/pts/0
smsc0: error: usb error on tx: USB_ERR_IOERROR
smsc0: warning: bulk read error, USB_ERR_IOERROR
smsc0: warning: Failed to read register 0x118
smsc0: warning: Failed to read register 0x114
smsc0: warning: MII is busy
smsc0: warning: Failed to read register 0x114
smsc0: warning: MII is busy
smsc0: warning: Failed to read register 0x2c
smsc0: warning: failed to read initial AFC_CFG, error 18
smsc0: warning: Failed to read register 0x114
smsc0: warning: MII is busy
smsc0: at uhub1, port 1, addr 3 (disconnected)
smsc0: warning: Failed to read register 0x114
smsc0: warning: MII is busy
smsc0: warning: Failed to read register 0x114
smsc0: warning: MII is busy
smsc0: warning: Failed to read register 0x114
smsc0: warning: MII is busy
smsc0: warning: Failed to read register 0x114
smsc0: warning: MII is busy
smsc0: warning: Failed to read register 0x114
smsc0: warning: MII is busy
smsc0: warning: Failed to read register 0x114
smsc0: warning: MII is busy
smscphy0: detached
miibus0: detached
smsc0: detached
ping: sendto: No route to host
usbd_setup_device_desc: getting device descriptor at addr 3 failed,
USB_ERR_SHORT_XFER
ping: sendto: No route to host
smsc0 on uhub1
smsc0: on usbus1
smsc0: chip 0xec00, rev. 0002
miibus0: on smsc0
smscphy0: PHY 1 on miibus0
smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
smsc0: chip 0xec00, rev. 0002
ping: sendto: No route to host
ping: sendto: No route to host
There were no further ping errors and I was able to log in via ssh before
noticing
the errors on the console. An immediate run of usbconfig dump_stats reported:
root@pelorus:/usr/home/bob # usbconfig dump_stats
ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=SAVE (0mA)
{
UE_CONTROL_OK : 0
UE_ISOCHRONOUS_OK : 0
UE_BULK_OK : 0
UE_INTERRUPT_OK : 0
UE_CONTROL_FAIL : 0
UE_ISOCHRONOUS_FAIL : 0
UE_BULK_FAIL: 0
UE_INTERRUPT_FAIL : 0
}
ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (2mA)
{
UE_CONTROL_OK : 791
UE_ISOCHRONOUS_OK : 0
UE_BULK_OK : 0
UE_INTERRUPT_OK : 4
UE_CONTROL_FAIL : 0
UE_ISOCHRONOUS_FAIL : 0
UE_BULK_FAIL: 0
UE_INTERRUPT_FAIL : 0
}
ugen1.3: at usbus1, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=ON (2mA)
{
UE_CONTROL_OK : 15495
UE_ISOCHRONOUS_OK : 0
UE_BULK_OK : 1435
UE_INTERRUPT_OK : 0
UE_CONTROL_FAIL : 29
UE_ISOCHRONOUS_FAIL : 0
UE_BULK_FAIL: 2
UE_INTERRUPT_FAIL : 0
}
ugen1.4: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps)
pwr=ON (90mA)
{
UE_CONTROL_OK : 31
UE_ISOCHRONOUS_OK : 0
UE_BULK_OK : 25290
UE_INTERRUPT_OK : 0
UE_CONTROL_FAIL : 0
UE_ISOCHRONOUS_FAIL : 0
UE_BULK_FAIL: 3
UE_INTERRUPT_FAIL : 0
}
ugen1.5: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
(500mA)
{
UE_CONTROL_OK : 83
UE_ISOCHRONOUS_OK : 0
UE_BULK_OK : 5527
UE_INTERRUPT_OK : 0
UE_CONTROL_FAIL : 0
UE_ISOCHRONOUS_FAIL : 0
UE_BULK_FAIL: 61
UE_INTERRUPT_FAIL : 0
}
root@pelorus:/usr/home/bob #
Might this suggest any further experiments? I believe this is the first time
errors other than on the boot drive have been reported using dump_stats.
Thanks for reading,
bob prohaska
Re: 60+% ping packet loss on Pi3 under -current and stable-13
The -current Pi3 that's having ping trouble behaves sligtly differently compared to the stable-13 example. A one-hop (no NAT) ping looks like: [test host is rebooting] ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down 64 bytes from 50.1.20.28: icmp_seq=35 ttl=64 time=52.568 ms [ue0 just came up] 64 bytes from 50.1.20.28: icmp_seq=49 ttl=64 time=4.663 ms 64 bytes from 50.1.20.28: icmp_seq=51 ttl=64 time=1.044 ms [ntp set time] [I started outbound ping. Should have waited a bit longer.] 64 bytes from 50.1.20.28: icmp_seq=53 ttl=64 time=0.929 ms 64 bytes from 50.1.20.28: icmp_seq=55 ttl=64 time=0.902 ms 64 bytes from 50.1.20.28: icmp_seq=80 ttl=64 time=1.140 ms 64 bytes from 50.1.20.28: icmp_seq=81 ttl=64 time=1.064 ms 64 bytes from 50.1.20.28: icmp_seq=88 ttl=64 time=1.070 ms 64 bytes from 50.1.20.28: icmp_seq=108 ttl=64 time=0.967 ms 64 bytes from 50.1.20.28: icmp_seq=109 ttl=64 time=0.911 ms 64 bytes from 50.1.20.28: icmp_seq=110 ttl=64 time=0.913 ms ^C --- www.zefox.org ping statistics --- 112 packets transmitted, 11 packets received, 90.2% packet loss round-trip min/avg/max/stddev = 0.902/6.016/52.568/14.759 ms [no explicit errors on console] Uname -a on the test host reports FreeBSD 14.0-CURRENT #58 main-n255160-9a3583bfbd1: Wed May 4 21:47:21 PDT 2022 b...@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC Am I correct in thinking that "main-n255160" is a sort of serial number that can be used to compare branch revisions by age? Thanks for reading, bob prohaska
Re: Gigabit for FreeBSD
I am running two FreeBSD (4.4-stable) systems here with the following GigE cards: Linksys EG1064 SMC 9462TX They both use the National Semiconductor chip and are supported by the nge driver. Both are in dual Athlon systems (Tyan S2460 MBs), connected to a Linksys EG0008 GigE switch, and are working well. I am experiencing three relatively small issues: 1. The SMC card seems to take a couple of tries to get the link up. I usually get several messages at boot time that the gigabit link is up from the driver, so it appears that it comes up put quickly drops one or more times before finally staying up (I have never seen it drop once the system is running). 2. The Linksys card appears to be about 25% slower than the SMC card. With netperf I get up to 85 MB/s with the SMC card and only 65 MB/s with the SMC. Note that the Linksys card is in the faster of the two systems (1.533 GHz CPUs vs. 1.2 GHz for the SMC card's CPUs). 3. If I statically link the driver in the kernel it disrupts my sound card. This doesn't happen if I dynamically load the driver. However, all of these are easily ignored or worked around in my environment. Bob On Mon, Dec 10, 2001 at 10:08:43AM +0100, Martin Stiemerling wrote: > D-LINK DGE500-SX works good! > > > --On Freitag, Dezember 07, 2001 10:22:44 -0800 David Smithson > <[EMAIL PROTECTED]> wrote: > > > Hi all. Does anyone know of a good stable 1000baseTX gigabit network > > adapter that works well with FreeBSD? I have this Netgear adapter that > > seems to have problems. Help is -- of course -- appreciated. Thanks. > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-net" in the body of the message > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message -- Bob Willcox Boucher's Observation: [EMAIL PROTECTED] He who blows his own horn always plays the music Austin, TX several octaves higher than originally written. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Gigabit for FreeBSD
On Mon, Dec 10, 2001 at 10:20:55AM -0800, David Smithson wrote: > > I am experiencing three relatively small issues: > > > > 1. The SMC card seems to take a couple of tries to get the link up. I > >usually get several messages at boot time that the gigabit > > link is up > >from the driver, so it appears that it comes up put > > quickly drops one > >or more times before finally staying up (I have never seen it drop > >once the system is running). > > > > I have a similar issue with the nge driver. Ocasionally I will get repeated >messages "gigabit link up" or something like that. It's not a regular occurance >though, and the link never actually comes up. I wonder if there could be some >conflict between the Netgear interface and my Asante switch. Perhaps so. I get this (though the link usually does finally stay up) with both of the SMC cards that I have tried with my Linksys switch. On the other hand, my Linksys card always comes up on the first try with the Linksys switch. Unfortunately, it's also 25% slower than the SMC cards :-( Bob -- Bob Willcox Boucher's Observation: [EMAIL PROTECTED] He who blows his own horn always plays the music Austin, TX several octaves higher than originally written. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Unexpected EADDRINUSE
Some of our regression tests fail randomly on FreeBSD with an unexpected EADDRINUSE error. We didn't see this problem with 4.7, but we see it in 4.11, 5.4, and 6.0. We don't see this behavior on any of our other supported platforms. We investigated the problem, and managed to come up with a way to reproduce the problem outside of our regression test suite. To reproduce, first start the sink with "python sink.py". Then run "python conn.py". When we do this, we get EADDRINUSE after a short time. Since we're binding the connecting socket to the wild port, this shouldn't happen. If the s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) call is removed, the problem seems to go away. The setting of SO_REUSEADDR is there because that's what some perhaps too-generic make-a-socket library code did; we realize it's not technically needed. Nevertheless, we don't see why it should fail either :). I looked at the differences between 4.7 and later kernels but didn't manage to figure out how the changes caused this change in behavior. Regards, /Bob ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unexpected EADDRINUSE
Sorry my attachments didn't make it :)
#
# sink.py
#
import socket
import traceback
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('127.0.0.1', 12345))
s.listen(5)
while True:
try:
n = s.accept()[0]
d = None
while d != '':
d = n.recv(100)
n.close()
except socket.error:
pass
#
# conn.py
#
import socket
import traceback
n = 0
while True:
try:
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('127.0.0.1', 0))
print s.getsockname()
s.connect(('127.0.0.1', 12345))
s.close()
n += 1
if n > 0 and n % 1000 == 0:
print n
except Exception, e:
traceback.print_exc()
break
print n
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Removal of netns - politically correct version
Hi, Here's a hint: "The Apollo Domain and XNS networking protocols will no longer be offered after Cisco IOS Release 12.2. Information about these protocols will not appear in future releases of the Cisco IOS software documentation set." http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a008007fba7.html He's dead, Jim. -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED] fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Removal of netns - politically correct version
Hi At 08:53 5/3/03, Terry Lambert wrote: [...] The code is still useful as a simple implementation, much more easily understood by the student than the current TCP/IP stack, for certain. The same is true for netipx (wc -l *.[ch] is almost identical). -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED] fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: rl interface drops out occasionally
Greets > I've noticed that > every now > and then the network interface drops out. I can ifconfig destroy and > then create it again and the network interface comes back. This > machine serves nfs/smb/rsync exclusively and nothing more > (2-3 gigs of > traffic is moved per day). I had the same description of problem. I shut off the onboard NIC and installed a new rl and problem was solved. I spent several weeks testing different things. For the 5 or ten bucks for a new rl card, it is worth spending it. Sincerely Bob DeBolt Pres / CTO Starblanket Research 1-877-280-3695 Calgary 280-3695 [EMAIL PROTECTED] 0x44E4A96B ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPv6 Ideas
I was in a similar position to you not that long ago. I got my LAN all dual stack and was a happy camper. I wanted 100% IPv6 and never to see another RFC 1918 address on my network again. Unfortunately it's just not practical. My ReadyNAS doesn't talk v6. My mac doesn't appear to like v6 for the file transfer protocols it supports. My iPhone doesn't do v6. The applications just aren't ready to live in a v6-only world. I suggest leaning on your vendors whenever you can so that they no longer can say "no one is asking for it." A boring, un-bumped thread asking for IPv6 support in the iPhone: http://discussions.apple.com/thread.jspa?threadID=1960260&tstart=0 Getting back to your question. It is my understanding that this IVI proposal is the most likely to become an officially adopted standard: http://tools.ietf.org/html/draft-xli-behave-ivi-01 That's being done as part of the behave working group: http://www.ietf.org/html.charters/behave-charter.html If anyone were to begin working on something like this this they'd probably want to think about following that proposal. I too am interested in working on this. Just haven't sat down to really start thinking about it yet. -Bob Message: 14 Date: Thu, 23 Apr 2009 21:14:50 -0400 From: Nathan Lay Subject: IPv6 Ideas To: freebsd-net@freebsd.org Message-ID: <49f1128a.3080...@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I started playing with IPv6 on my home network with the intent to transition over. While many things work quite well, IPv6 technology in general still seems to have some rough edges. In terms of FreeBSD support, rtadvd and rtsol do not yet support (easily? -O option in rtadvd/rtsold) RFC5006 (Router Advertisements Option for DNS Configuration) which make it inconvenient to use mobile devices (like laptops) on an IPv6 network. I haven't had much luck with net/radvd. Is this something that could be improved? I'd be willing to implement this support, but I have very little time to spare (writing thesis). To be backward compatible with IPv4, I had a look at faith and faithd and while these tools are ingenius, I don't think they are good enough for transitioning to IPv6. I imagine it is possible to write an IPv6->IPv4 NAT daemon that uses faith to capture and restructure IPv6/IPv4 packets. Though, it really seems like this is the firewall's job A pf rule like: nat on $inet4_if inet to any from $lan_if:network6 -> ($inet4_if) would be extremely convenient. I'm aware pf doesn't support the token :network6 ... its just a wishful example. The IPv6 mapped IPv4 addresses would be the standard :::0:0/96 prefix. I imagine that this is very difficult to implement but I don't see why it wouldn't be possible. If a firewall supported this kind of NAT, a home network could easily deploy IPv6 and be backward compatible. Well, not quite, I guess BIND would have to serve IPv6 mapped IPv4 addresses to IPv6 queries. Oh yeah, one annoyance on 7-STABLE, it seems like pf is started before IPv6 rc.conf options are processed (including IPv6 address assignment) breaking inet6 rules that involve $if:network. Comments? Other than that, this has been one hell of a fun experience. Best Regards, Nathan Lay ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 Ideas
What are your problems with using radvd? I have used it quite a bit on FreeBSD (6.1) without any hassle. It's even written quite nicely in my experience so working on patches for it should be quite do-able if there are features missing. He's saying that the router announcements don't contain any DNS server information. There's an extension/option that can be enabled with router advertisements to make it send this information, similar in function to how DHCP sends out extra info like the default gateway, DNS server, NTP server, WINS servers, etc. To my knowledge this wasn't around when the Kame guys were working on this stuff. I don't think a lot of time has been spent updating the v6 support applications since then and that's why we don't have this feature. This isn't a big deal in dual-stack networks because the clients just do DNS over v4 with whatever the DHCP server gave. In a pure-v6 world... In hindsight it's an obvious oversight that it wasn't included in the first place. -Bob ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
IPv6 duplicate address detection
I'm working on a piece of software that, among other things, allows an administrator to easily configure IPv6 interfaces on a FreeBSD host. I've run into a problem where whenever I reconfigure an interface with an IPv6 address FreeBSD marks the new address as being a duplicate. The problem is that I'm following RFC 2461 [1] in that I send an unsolicited neighbor advertisement to ff02::1 immediately after configuring the interface. This unsolicited neighbor advertisement is interpreted by FreeBSD as being a response to the neighbor solicitation it sends around the same time as part of duplicate address detection (DAD). This leads FreeBSD to think that the address is already in use, it doesn't notice that it is the one already using it. I want this to mean that there's a bug in the IPv6 implementation in that it shouldn't trigger a DAD failure if it sees an unsolicited NA from itself when sent from the same physical interface. An alternative view on this is that I shouldn't be sending out any packets, especially unsolicited NAs, using or referencing a tentative address. I'm writing to freebsd-net to ask what others think. If people agree that the address shouldn't be marked as a duplicate then I have a python script that reproduces the problem and a patch to nd6_nbr.c to attach to a problem report that I'll file. -Bob [1] RFC 2461 section 7.2.6 paragraph 1: In some cases a node may be able to determine that its link-layer address has changed (e.g., hot-swap of an interface card) and may wish to inform its neighbors of the new link-layer address quickly. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 duplicate address detection
On 5/6/09 7:27 AM, "Bruce Simpson" wrote: >> The problem is that I'm following RFC 2461 [1] in that I send an unsolicited >> neighbor advertisement to ff02::1 immediately after configuring the >> interface. >> > > How are you doing this? Do you do this from the kernel or from your own > userland code? Userland code. SOCK_RAW and IPPROTO_ICMPV6. > > Normally the kernel does DAD for you when a new IPv6 address is > configured, and you shouldn't need to do it manually. Just to be clear, I'm not trying to do DAD. You mention later that this sounds like gratuitous ARP and that's the best analogy for what I'm doing. I fire off a single packet into the wild and hope that my neighbors see my new link-layer address (we do NIC failover). > It sounds like what you are trying to do is useful (a bit like > gratuitous ARP) but I wonder exactly what conditions it's triggering in > nd6_nbr.c which would cause it to interpret what you send in this way. There's not really anything in nd6_nbr.c to prevent this behavior. I have a patch that changes this. I don't know if it's making an invalid assumption or not. In my basic tests it avoids the behavior where my IP gets marked as a duplicate but still allows DAD to work when the address really is a dup. --- nd6_nbr.c.backupMon May 4 10:12:20 2009 +++ sys/netinet6/nd6_nbr.cMon May 4 14:19:30 2009 @@ -618,8 +618,16 @@ lladdr = (char *)(ndopts.nd_opts_tgt_lladdr + 1); lladdrlen = ndopts.nd_opts_tgt_lladdr->nd_opt_len << 3; } +/* Is the source address of this packet one of my + * addresses on this same interface? If so this packet was sent by me + * and should not trigger a DAD failure. + */ +ifa = (struct ifaddr *)in6ifa_ifpwithaddr(ifp, &(ip6->ip6_src)); +if (ifa) +goto freeit; + > This seems like a bug. > Have you looked in the KAME repo to see if it got fixed there? > Perhaps NetBSD have already fixed it in their import of KAME? I took a look through head of the kame cvsweb sources and don't see any differences from 6.3 sources I have. They have some MIP6 code in place but that's the only difference I see. > >> An alternative view on this is that I shouldn't be sending out any packets, >> especially unsolicited NAs, using or referencing a tentative address. >> > > That can be tricky to implement. There is a function > in6ifa_ifpforlinklocal() which takes various flags. It is told to skip > tentative addresses or duplicates by passing IN6_IFF_NOTREADY. Normally > this will return the ifa pointer to the link-local address which was > auto-configured on the inerface. Being in userland I don't think I can call this. However, I discovered the SIOCGIFAFLAG_IN6 ioctl which gives me back the flags for an tuple. In this way I can poll for whether or not this IP is tentative or not. Similarly I can tell whether DAD failed. > > Can you try HEAD sources and disable IPv6 multicast loopback by default > (net.inet6.ip6.mcast.loop, off the top of my head) ? > > It is possible that your ff02::1 packet is being looped back and somehow > the NA/NS code is interpreting it as on-wire traffic. > 7.x will loop back by default. You could even try just setting > IPV6_MULTICAST_LOOP to 0 in your userland DAD code. I don't have a HEAD kernel handy. However, this socket option was a nice pointer, thank you. Setting this to 0 does prevent the behavior I was seeing. I guess this makes it extra clear that the multicast packet I'm sending is simply being looped back in. I'm guessing that the next step is for me to file a PR with this information? Or what do you suggest? -Bob ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 duplicate address detection
On 5/6/09 3:06 PM, "JINMEI Tatuya / 神明達哉" wrote: > I'm afraid we need clarification first...what do you mean by > "reconfigure an interface with an IPv6 address"? Do you mean adding a > new IPv6 address to an interface? If so, I'm not sure why you > referred to the following part of RFC2461 (btw the RFC was updated by > RFC4861): We have a crude form of NIC pairing in our software. We allow someone to logically pair two interfaces together. This is implemented by `ifconfig down` both interfaces, configure them both the same, then `ifconfig up` the primary interface. We then monitor the link state of the primary interface. If the state goes to down, we `ifconfig down` the primary NIC and then `ifconfig up` the secondary NIC. This has the effect of changing the link layer address associated with a given IPv6 address. After we do this we send out the unsolicited NA to update whatever switch we're plugged into. We do this today with IPv4 and ARP and it works fine. >> [1] RFC 2461 section 7.2.6 paragraph 1: >> >>In some cases a node may be able to determine that its link-layer >>address has changed (e.g., hot-swap of an interface card) and may >>wish to inform its neighbors of the new link-layer address quickly. > > this example talks about the case where the link-layer address changes > for an existing address, not where a new address is configured. I hope the example I gave above helps to clarify that I am trying to handle a case where the link-layer address has changed. However, I'll admit that I had been planning on sending the unsolicited NA after any ifconfig commands were executed. So long as I'm not flooding the network it doesn't seem harmful and potentially seems useful to avoid a few seconds of downtime while the network figures things out. -Bob ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 duplicate address detection
I never actually tested the NIC pairing scenario and was only testing the naive "add a new IP, fire off an unsolicited NA for that IP." I did just test the NIC pairing and you are right, if the interface is down when it is configured we don't run DAD. Which does seem weird but that would be a different thread. I guess that changes my question quite a bit. If you randomly fire off an unsolicited NA right after configuring an interface should that cause a DAD failure? -Bob On 5/6/09 4:55 PM, "JINMEI Tatuya / 神明達哉" wrote: > At Wed, 06 May 2009 15:49:45 -0700, > Bob Van Zant wrote: > >>> I'm afraid we need clarification first...what do you mean by >>> "reconfigure an interface with an IPv6 address"? Do you mean adding a >>> new IPv6 address to an interface? If so, I'm not sure why you >>> referred to the following part of RFC2461 (btw the RFC was updated by >>> RFC4861): > >> We have a crude form of NIC pairing in our software. We allow someone to >> logically pair two interfaces together. This is implemented by `ifconfig >> down` both interfaces, configure them both the same, then `ifconfig up` the >> primary interface. We then monitor the link state of the primary interface. >> If the state goes to down, we `ifconfig down` the primary NIC and then >> `ifconfig up` the secondary NIC. This has the effect of changing the link >> layer address associated with a given IPv6 address. After we do this we send >> out the unsolicited NA to update whatever switch we're plugged into. > > Okay, thanks for the explanation. But I still don't understand one > thing: why is DAD triggered for the address on the secondary NIC? > Unless someone has changed the code recently, the FreeBSD > (KAME-derived) IPv6 stack shouldn't trigger DAD for an existing > address simply because the interface becomes 'up' (this behavior may > be debatable per se, but that's a different question). Did you > perhaps make the address "tentative" by hand after configuring the > address? > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 duplicate address detection
Well that goes all the way back to my first email :-) "An alternative view on this is that I shouldn't be sending out any packets, especially unsolicited NAs, using or referencing a tentative address." This makes sense. I'll stop doing bad things now :-) Thanks for your input and clearing this up for me. -Bob On 5/6/09 10:47 PM, "JINMEI Tatuya / 神明達哉" wrote: > At Wed, 06 May 2009 17:17:52 -0700, > Bob Van Zant wrote: > >> I guess that changes my question quite a bit. If you randomly fire off an >> unsolicited NA right after configuring an interface should that cause a DAD >> failure? > > Actually, in that case you shouldn't send out the NA in the first > place because you're in the middle of DAD, trying to confirming the > uniqueness of the target address. If you want to send an unsolicited > NA for an address on which DAD is performed for any reason, you should > wait until DAD is completed. > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > ___ > 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"
Debugging a netgraph node
I'm experimenting with netgraph to try to implement an IPv6 -> IPv4 gateway, as specified here: http://tools.ietf.org/html/draft-xli-behave-ivi-02 This is my first time ever working with netgraph and I admit to being a bit lost. I have a netgraph node that gets wired up with an ng_ether node. My lower hook gets wired to the ng_ether lower hook and my upper to his upper. It's receiving IPv6 + UDP packets, creating IPv4 + UDP packets and then writing the new packets out with NG_FWD_NEW_DATA. I'm perfectly willing to waste time making stupid mistakes on this project, however, right now I'm stuck. I can't "find" the translated packets I'm writing anywhere to see what, if anything, is wrong with them. They don't show up in tcpdump on the local machine (I've tried writing to both the upper and lower hook). They don't show up in tcpdump on other machines on the network. I tried attaching nghook to the "orphans" hook of the ng_ether node but it doesn't appear to be seeing any data. netstat -s -p udp doesn't show any packets when my node is enabled (I think this means my node is effectively swallowing them). I've tried to figure out how to wire in an ng_tee node but I'm a little lost as to how to do this (I still haven't figured out the ngctl syntax). Any tips for figuring out what I'm doing wrong? Debug options to enable that will show me more information about what's happening after I call NG_FWD_NEW_DATA? If I got ng_tee wired in would it's tap hooks show me what I want? A better way to try to tee the data? Thanks, Bob ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
IPv6 traffic between two hosts not flowing
I have 2 FreeBSD machines each with 3 ethernet interfaces each with an IPv6 address. Here's a table showing how the two machines are connected. To try to blame the switch or its configuration I have tried directly connecting the machines. The results were the same. 6.34948 6.2 --- --- fxp0 em2 fc00:dada::47 fc00:dada::2 bge0 em0 fc00:dada:1::47 fc00:dada:1::2 bge1 em1 fc00:dada:2::47 fc00:dada:2::2 Traffic from fxp0 to em2 works fine. bge0 to em0 and bge1 to em1 doesn't work as I'll explain below and is the reason I'm writing to the list. This host is able to communicate with it's IPv6 neighbor over the fxp0 interface, however, neither of the bge interfaces are able to communicate with their peers. ndp(8) output on the 6.3 machine (with bge interfaces) seems to highlight something weird. In addition to the errors occurring, the Netif column for fc00:dada:1::47 shows fxp0. ifconfig shows that address on bge0. The same is true for fc00:dada:2::47; in ndp it shows up on fxp0 but ifconfig thinks it's on bge1 (it should be). The linklayer address being "(incomplete)" also seems weird given that this is a normal ethernet interface on the local machine. $ ndp -an Neighbor Linklayer Address Netif ExpireS Flags fc00:dada::2 0:e:c:b4:13:8f fxp0 22h38m10s S R fc00:dada::470:2:b3:e7:4a:56 fxp0 permanent R ndp: ioctl(SIOCGNBRINFO_IN6): Invalid argument ndp: failed to get neighbor information fc00:dada:1::47 (incomplete)fxp0 ndp: ioctl(SIOCGNBRINFO_IN6): Invalid argument ndp: failed to get neighbor information fc00:dada:2::47 (incomplete)fxp0 fe80::20d:56ff:fe70:a9ae%bge00:d:56:70:a9:ae bge0 permanent R fe80::20d:56ff:fe70:a9af%bge10:d:56:70:a9:af bge1 permanent R fe80::202:b3ff:fee7:4a56%fxp00:2:b3:e7:4a:56 fxp0 permanent R Output from ifmcstat looks correct to me (mostly the same as fxp0 but with the appropriate addresses different). I did find this message in the logfile at least once: nd6_storelladdr: sdl_alen == 0 If I do a ping6 in between the two hosts and then run tcpdump on either of the bge interfaces I can see neighbor discovery traffic going back and forth. If the ping is from the bge interface to the corresponding em interface then all I ever see is the NDP traffic. If the ping is from the em interface to the corresponding bge interface then I see a normal solicitation and advertisement followed by ICMP echo requests (there are never any replies). The 6.2 machine's ndp cache looks correct. The 6.3 machine's ndp cache is the one pasted above. I feel like I'm just rambling here and not necessarily putting together a sane question. If this is making sense to anyone and it isn't immediately obvious what's going on please ask me some follow up questions. In addition to all of this, after what appears to be about an hour of sending ping packets that go nowhere and pulling interfaces in and out of promiscuous mode (tcpdump) the system appears to deadlock. I don't have any proof that it's deadlock other than a completely unresponsive box that needs to have the power cable removed. It's happened twice so far this afternoon. Thanks for reading this far, Bob ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 traffic between two hosts not flowing
The problem ended up being a semi-broken em (yes, em, bge wasn't the problem like I originally thought) driver in 6.2. The driver wasn't bringing in ethernet multicast frames (required for ndp to work) and without ndp things weren't working. If the interface was put into promiscuous mode for a few seconds ndp could take place and everything worked fine. Upgrading the kernel to 6.3 made the problem go away. Just in case it's useful to anyone, these are the 3 em devices I had on this machine (a Dell 2850): e...@pci6:7:0:class=0x02 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 e...@pci7:8:0:class=0x02 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 e...@pci9:4:0:class=0x02 card=0x10028086 chip=0x10268086 rev=0x04 hdr=0x00 em2 was the only device functioning properly on 6.2. -Bob On 7/23/09 9:32 PM, "Julian Elischer" wrote: > Bob Van Zant wrote: >> I have 2 FreeBSD machines each with 3 ethernet interfaces each with an IPv6 >> address. >> >> Here's a table showing how the two machines are connected. To try to blame >> the switch or its configuration I have tried directly connecting the >> machines. The results were the same. >> >> 6.34948 6.2 >> --- --- >> fxp0 em2 >> fc00:dada::47 fc00:dada::2 >> >> bge0 em0 >> fc00:dada:1::47 fc00:dada:1::2 >> >> bge1 em1 >> fc00:dada:2::47 fc00:dada:2::2 >> >> Traffic from fxp0 to em2 works fine. >> bge0 to em0 and bge1 to em1 doesn't work as I'll explain below and is the >> reason I'm writing to the list. >> >> >> This host is able to communicate with it's IPv6 neighbor over the fxp0 >> interface, however, neither of the bge interfaces are able to communicate >> with their peers. >> >> ndp(8) output on the 6.3 machine (with bge interfaces) seems to highlight >> something weird. In addition to the errors occurring, the Netif column for >> fc00:dada:1::47 shows fxp0. ifconfig shows that address on bge0. The same is >> true for fc00:dada:2::47; in ndp it shows up on fxp0 but ifconfig thinks >> it's on bge1 (it should be). The linklayer address being "(incomplete)" also >> seems weird given that this is a normal ethernet interface on the local >> machine. > > I'm going to guess that if the other connections were disconnected, > the 2nd and 3rd pairs would work. > > I'm also guessing that if you closely look at the data between the 2nd > and 3rd pairs you will somewhere see the addresses of the first pair > in there. FreeBSD has often suffered when trying to run connections in > parallel, even in IPV4. > > I believe this has been fixed in 8.x to some extent.. > > > >> >> >> $ ndp -an >> Neighbor Linklayer Address Netif ExpireS >> Flags >> fc00:dada::2 0:e:c:b4:13:8f fxp0 22h38m10s S R >> fc00:dada::470:2:b3:e7:4a:56 fxp0 permanent R >> ndp: ioctl(SIOCGNBRINFO_IN6): Invalid argument >> ndp: failed to get neighbor information >> fc00:dada:1::47 (incomplete)fxp0 >> ndp: ioctl(SIOCGNBRINFO_IN6): Invalid argument >> ndp: failed to get neighbor information >> fc00:dada:2::47 (incomplete)fxp0 >> fe80::20d:56ff:fe70:a9ae%bge00:d:56:70:a9:ae bge0 permanent R >> fe80::20d:56ff:fe70:a9af%bge10:d:56:70:a9:af bge1 permanent R >> fe80::202:b3ff:fee7:4a56%fxp00:2:b3:e7:4a:56 fxp0 permanent R >> >> >> Output from ifmcstat looks correct to me (mostly the same as fxp0 but with >> the appropriate addresses different). >> >> I did find this message in the logfile at least once: >> >> nd6_storelladdr: sdl_alen == 0 >> >> >> If I do a ping6 in between the two hosts and then run tcpdump on either of >> the bge interfaces I can see neighbor discovery traffic going back and >> forth. > > but not correct probably or it would be stored in the Link Level tables. > >> >> If the ping is from the bge interface to the corresponding em interface then >> all I ever see is the NDP traffic. >> >> If the ping is from the em interface to the corresponding bge interface then >> I see a normal solicitation and advertisement followed by ICMP echo requests >> (there are never any replies). The 6
Re: kern/116837: ifconfig tunX destroy: panic
The following reply was made to PR kern/116837; it has been noted by GNATS. From: Bob Van Zant <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: kern/116837: ifconfig tunX destroy: panic Date: Sun, 6 Jan 2008 22:46:09 +0530 My FreeBSD 7.0-PRERELEASE box has been running into this problem a lot recently when I reset my ppp connection to counteract the effects of having a very poor ISP. I would like to fix this bug. Is there anyone that can help me identify what the proper behavior is? In my case the repro is something along the lines of: - Create ppp connection (tun0) - Create six-to-four connection (stf0) - The ppp connection gets wedged - /etc/rc.d/ppp stop - ifconfig tun0 destroy - kernel panic My hunch is that the stf0 interface being "on top" of tun0 is causing the problem. I've changed the script, maybe the panic will stop happening. But what should the behavior be? Should the if_tun code make an attempt to clean up whatever it can and then just destroy the interface like requested? Or should it return some sort of error and the ifconfig request to destroy the interface fails? The if_tap code appears to have the same assert in its destroy function and we may want to fix that as well. I tend to get a few spare hours during any given week to play with these sorts of things and I'd like to be able to help out with this one. Any sort of direction folks can give in working towards a solution will be appreciated. -Bob ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/116837: [tun] [panic] [patch] ifconfig tunX destroy: panic
The following reply was made to PR kern/116837; it has been noted by GNATS.
From: Bob Van Zant <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Subject: Re: kern/116837: [tun] [panic] [patch] ifconfig tunX destroy: panic
Date: Thu, 24 Jan 2008 12:40:19 +0530
I applied the patch in the prior comment and now I get this, different,
kernel panic (yanked from dmesg):
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address= 0xdeadc0e6
fault code= supervisor write, page not present
instruction pointer= 0x20:0xc07903b5
stack pointer= 0x28:0xd62a2ab4
frame pointer= 0x28:0xd62a2ac8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process= 3091 (ppp)
trap number= 12
panic: page fault
cpuid = 0
Uptime: 1h58m15s
Physical memory: 499 MB
Dumping 154 MB: 139 123 107 91 75 59 43 27 11
Dump complete
Plopping into kgdb:
(kgdb) list *0xc07903b5
0xc07903b5 is in clear_selinfo_list (/usr/src/sys/kern/sys_generic.c:1066).
1061{
1062struct selinfo *si;
1063
1064mtx_assert(&sellock, MA_OWNED);
1065TAILQ_FOREACH(si, &td->td_selq, si_thrlist)
1066si->si_thread = NULL;
1067TAILQ_INIT(&td->td_selq);
1068}
1069
1070/*
(kgdb) bt
#0 doadump () at pcpu.h:195
#1 0xc075957f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc075984b in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3 0xc0a41913 in trap_fatal (frame=0xd62a2a74, eva=3735929062)
at /usr/src/sys/i386/i386/trap.c:899
#4 0xc0a41af0 in trap_pfault (frame=0xd62a2a74, usermode=0, eva=3735929062)
at /usr/src/sys/i386/i386/trap.c:812
#5 0xc0a42432 in trap (frame=0xd62a2a74) at
/usr/src/sys/i386/i386/trap.c:490
#6 0xc0a289bb in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc07903b5 in clear_selinfo_list (td=0xc321d220)
at /usr/src/sys/kern/sys_generic.c:1065
#8 0xc0791168 in kern_select (td=0xc321d220, nd=11, fd_in=0x28413c00,
fd_ou=0x28414000, fd_ex=0x28414400, tvp=0x0)
at /usr/src/sys/kern/sys_generic.c:794
#9 0xc079131e in select (td=0xc321d220, uap=0xd62a2cfc)
at /usr/src/sys/kern/sys_generic.c:663
#10 0xc0a41dc3 in syscall (frame=0xd62a2d38)
at /usr/src/sys/i386/i386/trap.c:1035
#11 0xc0a28a20 in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:196
#12 0x0033 in ?? ()
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/116837: [tun] [panic] [patch] ifconfig tunX destroy: panic
The following reply was made to PR kern/116837; it has been noted by GNATS. From: Bob Van Zant <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: Subject: Re: kern/116837: [tun] [panic] [patch] ifconfig tunX destroy: panic Date: Tue, 05 Feb 2008 10:04:08 +0530 I've been running this patch for the past ~6 days and haven't seen a panic yet. Prior to this I was panicing 2-3 times a day so I think this patch fixes the problem. I believe that this same problem exists with the tap interface. Should we fix it at the same time? -Bob ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PIM IPv4 user-level process
I'm interested in doing IPv4 multicast routing but want to avoid DVMRP.
I see kernel support for PIM both IPv4 and IPv6. But I can't find any
user-level process to run PIM IPv4. It seems odd that kernel support
would be present with no routing daemon. Am I missing something
obvious?
Thanks,
Bob
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PIM IPv4 user-level process
I've done some local ports before and I know enough about multicast
routing that I stand a chance of being able to come up with some
suitable patches. I even have a good test environment for it here with
Ciscos running PIM.
I probably won't have time to come up with an extensive patch set, but I
could probably make something work if the amount of patching required is
more modest.
Where would I find the sources to get started porting/patching?
Thanks,
Bob
On Fri, 2004-01-30 at 10:45, Bruce M Simpson wrote:
> On Fri, Jan 30, 2004 at 09:43:12AM -0600, Bob Van Valzah wrote:
> > I'm interested in doing IPv4 multicast routing but want to avoid DVMRP.
> > I see kernel support for PIM both IPv4 and IPv6. But I can't find any
> > user-level process to run PIM IPv4. It seems odd that kernel support
> > would be present with no routing daemon. Am I missing something
> > obvious?
>
> We don't have pimsd or pimdd for IPv4 in ports at the moment.
> Patches will be gratefully accepted!
>
> BMS
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PIM IPv4 user-level process
On Fri, 2004-01-30 at 10:45, Bruce M Simpson wrote: > We don't have pimsd or pimdd for IPv4 in ports at the moment. > Patches will be gratefully accepted! I downloaded xorp-0.5 to see if I could pull pimsd from it. A quick attempt to compile just pim resulted in an error. I did succeed in compiling the whole thing, but it sure looks like pim was meant to be used as part of the whole xorp thing rather than as a standalone. A port of the whole xorp world might be a better target than just the pim part. That wouldn't take much since it compiled easily. But it is a whopper--nearly 1 GB required to build. Bob ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
