Re: unknown USB vendor
On Fri, 24 May 2024 11:51:49 +0200 Mizsei Zoltán wrote: > Probably https://wikidevi.wi-cat.ru/AMPAK_AP6212 > > Peter J. Philipp írta 2024. máj.. 24, P-n 11:39 órakor: > > Hi, > > > > I got a "are you a human?" on google so I switched to qwant.com for > > searching > > but the search is not as good. I'm looking for the USB vendor of > > this USB > > vendor id. 0x02d0, and the device id is 0xa9a6. Afaict this is a > > ure(4) > > device with a builtin usb hub. But there is no other markings on > > the outside, related to manufacturer. It does not get detected by > > default on an April > > kernel code. It does have a micro-USB cable for the raspberry pi > > zero 2 that > > I wanted to use this with. > > > > Anyone have any details on these vendor and device id's? > > > > Best Regards, > > -pjp > > > > -- > > ** all info about me: lynx https://callpeter.tel, dig loc > > delphinusdns.org ** > From an RPI 4 dmesg: ... bwfm0 at sdmmc0 function 1 manufacturer 0x02d0, product 0xa9a6 at sdmmc0 ...
Re: unknown USB vendor
Probably https://wikidevi.wi-cat.ru/AMPAK_AP6212 Peter J. Philipp írta 2024. máj.. 24, P-n 11:39 órakor: > Hi, > > I got a "are you a human?" on google so I switched to qwant.com for > searching > but the search is not as good. I'm looking for the USB vendor of this > USB > vendor id. 0x02d0, and the device id is 0xa9a6. Afaict this is a > ure(4) > device with a builtin usb hub. But there is no other markings on the > outside, related to manufacturer. It does not get detected by default > on an April > kernel code. It does have a micro-USB cable for the raspberry pi zero > 2 that > I wanted to use this with. > > Anyone have any details on these vendor and device id's? > > Best Regards, > -pjp > > -- > ** all info about me: lynx https://callpeter.tel, dig loc delphinusdns.org ** -- --Z--
Re: unknown warning option '-Wno-unused-but-set-variable'
The current amd64 snapshot already contains clang 13. On Dec 19 15:23:34, y...@v007.vaio.ne.jp wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > > Kernel Makefiles were adjusted to compile with clang 13. Either take > > out the warnings so you can compile with old-clang, or rebuild clang. > > I'm trying to rebuild clang now. > I believe the steps are: > > # cd /usr/src/gnu/usr.bin/clang/ > # make clean && make obj && make > # make install > > (compilation on my machine ongoing...) > > why not adding an entry to www.openbsd.org/faq/current.html ? > > -- yozo. > > > -BEGIN PGP SIGNATURE- > > iQGzBAEBCgAdFiEEXaBuNN3EAffFuoZQoSJsq/akOnEFAmG+z6EACgkQoSJsq/ak > OnEURQv9F9T5665BXEorsFEkWKvXWQpgl91J3qxJrhTsYlSWGnby9mx6FeAsbvbH > QHcbihe6cDZYgfT4Dzq+UMZ9D7F4w+mjqOSuMwLXhcXiJRUkGW35BwCTQQaMUHGJ > CoCG4Uggb7ukn86AQhVFkjnjcHnXEkuoPjKSpMjFNg3oBi6WO+lC+JqvUYbQ8941 > gLx6AO6bOln7EV7cEDzxfpNByPzsIZquY85H0mfKllRfRiFdomb3Npq4cI/65O8D > WsvpOH7wlT1CYY3xZSa/D87tOkZscF5Z21tW2/ZLASb3Q2Gv8taYogOMQ4xyfbtm > 5rl5PaoDP/jmdDllFkeeIw8PjeY3XBkoPcNxuYrMfnY4FUQNDwvozgczNYPinDVL > qYn13FJl+m+y0Eamosw3RjL8O2JwBJ7aANjFv1rk1KyvH8eGmf738DZBFM1M7jRM > /ooSte2a7Bkhdt1Vg9xGh7Abubhb7R3OmGD0+rw6sfKnG17/hoZlV8j05Sfb7sNF > PEfkmlLf > =HRZ2 > -END PGP SIGNATURE- > >
Re: unknown warning option '-Wno-unused-but-set-variable'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > Kernel Makefiles were adjusted to compile with clang 13. Either take > out the warnings so you can compile with old-clang, or rebuild clang. I'm trying to rebuild clang now. I believe the steps are: # cd /usr/src/gnu/usr.bin/clang/ # make clean && make obj && make # make install (compilation on my machine ongoing...) why not adding an entry to www.openbsd.org/faq/current.html ? -- yozo. -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEXaBuNN3EAffFuoZQoSJsq/akOnEFAmG+z6EACgkQoSJsq/ak OnEURQv9F9T5665BXEorsFEkWKvXWQpgl91J3qxJrhTsYlSWGnby9mx6FeAsbvbH QHcbihe6cDZYgfT4Dzq+UMZ9D7F4w+mjqOSuMwLXhcXiJRUkGW35BwCTQQaMUHGJ CoCG4Uggb7ukn86AQhVFkjnjcHnXEkuoPjKSpMjFNg3oBi6WO+lC+JqvUYbQ8941 gLx6AO6bOln7EV7cEDzxfpNByPzsIZquY85H0mfKllRfRiFdomb3Npq4cI/65O8D WsvpOH7wlT1CYY3xZSa/D87tOkZscF5Z21tW2/ZLASb3Q2Gv8taYogOMQ4xyfbtm 5rl5PaoDP/jmdDllFkeeIw8PjeY3XBkoPcNxuYrMfnY4FUQNDwvozgczNYPinDVL qYn13FJl+m+y0Eamosw3RjL8O2JwBJ7aANjFv1rk1KyvH8eGmf738DZBFM1M7jRM /ooSte2a7Bkhdt1Vg9xGh7Abubhb7R3OmGD0+rw6sfKnG17/hoZlV8j05Sfb7sNF PEfkmlLf =HRZ2 -END PGP SIGNATURE-
Re: unknown warning option '-Wno-unused-but-set-variable'
Kernel Makefiles were adjusted to compile with clang 13. Either take
out the warnings so you can compile with old-clang, or rebuild clang.
What should have been done was to add no-op arguments for these warnings
into clang 11 to ease the transition to clang 13, but somehow no one did
it, huh.
Patrick
Am Fri, Dec 17, 2021 at 07:23:06PM +0100 schrieb Jan Stary:
> This is current/i386 on an ALIX.1E (dmesg below).
> The kernel does not build with the current cvs:
>
> cat /usr/src/sys/arch/i386/i386/genassym.cf
> /usr/src/sys/arch/i386/i386/genassym.cf | sh /usr/src/sys/kern/genassym.sh
> cc -no-integrated-as -g -Werror -Wall -Wimplicit-function-declaration
> -Wno-pointer-sign -Wframe-larger-than=2047 -Wno-address-of-packed-member
> -Wno-constant-conversion -Wno-unused-but-set-variable
> -Wno-gnu-folding-constant -ffreestanding -fno-pie -mretpoline -O2 -pipe
> -nostdinc -I/usr/src/sys -I/usr/src/sys/arch/i386/compile/GENERIC/obj
> -I/usr/src/sys/arch -I/usr/src/sys/dev/pci/drm/include
> -I/usr/src/sys/dev/pci/drm/include/uapi -I/usr/src/sys/dev/pci/drm/i915
> -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBUG
> -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DFFS -DFFS2
> -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT
> -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DTCP_ECN
> -DTCP_SIGNATURE -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX
> -DMROUTING -DMPLS -DBOOT_CONFIG -DUSER_PCICONF -DAPERTURE -DMTRR -DNTFS
> -DHIBERNATE -DPCIVERBOSE -DEISAVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL
> -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS="6" -DX86EMU
> -DONEWIREVERBOSE -DMAXUSERS=80 -D_KERNEL -MD -MP -MF assym.P > assym.h.tmp
> error: unknown warning option '-Wno-unused-but-set-variable'; did you mean
> '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-option]
> *** Error 1 in /usr/src/sys/arch/i386/compile/GENERIC (Makefile:1286
> 'assym.h')
>
>
> Jan
>
>
> OpenBSD 7.0-current (GENERIC) #345: Thu Dec 16 13:19:22 MST 2021
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem = 259207168 (247MB)
> avail mem = 238182400 (227MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 07/19/10, BIOS32 rev. 0 @ 0xfa950
> apm0 at bios0: Power Management spec V1.2 (slowidle)
> pcibios0 at bios0: rev 2.1 @ 0xf/0xdfb4
> pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf30/128 (6 entries)
> pcibios0: PCI Exclusive IRQs: 5 10 11
> pcibios0: no compatible PCI ICU found: ICU vendor 0x1022 product 0x2090
> pcibios0: Warning, unable to fix up PCI interrupt routing
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xc/0x8000 0xc8000/0xa800 0xef000/0x1000!
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class)
> 499 MHz, 05-0a-02
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
> mtrr: K6-family MTRR support (2 registers)
> amdmsr0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
> vga1 at pci0 dev 1 function 1 "AMD Geode LX Video" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
> vr0 at pci0 dev 13 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
> address 00:0d:b9:0e:9e:f4
> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit
> 3579545Hz timer, watchdog, gpio, i2c
> gpio0 at glxpcib0: 32 pins
> iic0 at glxpcib0
> pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0
> wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0:
> wd0: 1-sector PIO, LBA48, 15279MB, 31293360 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> pciide0: channel 1 ignored (disabled)
> auglx0 at pci0 dev 15 function 3 "AMD CS5536 Audio" rev 0x01: irq 11, CS5536
> AC97
> ac97: codec id 0x414c4770 (Avance Logic ALC203 rev 0)
> ac97: codec features headphone, 20 bit DAC, 18 bit ADC, No 3D Stereo
> audio0 at auglx0
> ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 5, version
> 1.0, legacy support
> ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 5
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00
> addr 1
> isa0 at glxpcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pcppi0 at isa0
Re: Unknown process modifying routing table
On Feb 06 12:18:40, ja...@jmp-e.com wrote: > I've disabled my VPN on the machine as well as dhclient, connecting via a > fixed static IP address and DNS servers. That would be a much aeasier environment to debug this. So please show your hostname.if, mygate and your routing table right after boot, and the log of script -c 'route -n monitor' route.log at least up to the first change.
Re: Unknown process modifying routing table
On Sat, Feb 06, 2021 at 02:16:20PM +0100, Otto Moerbeek wrote: > On Sat, Feb 06, 2021 at 12:18:40PM +, James wrote: > > > I've disabled my VPN on the machine as well as dhclient, connecting via a > > fixed static IP address and DNS servers. My routing table is still being > > modifed by PID 0 (which I assume to be the kernel) every 30 minutes or so. > > Ntpd is also disabled. > > > > I have also caught my machine communicating to one the of the IPs via TCP > > and have a pcap dump from wireshark. No actual data was sent other than a > > TCP timestamp. > > > > > If your default route is a VPN, > > > please show how you establish the VPN to be your default route. > > > > > The default route is established mannually in a script that is run after the > > VPN starts. Essentially it does the following: > > > > route add $VPN_HOST $DEFAULT_GW > > > > route change default $VPN_HOST > > > > > > I do not belive the VPN to be the cause of this problem. > > > > > > Any tips on debugging the kernel to track the cause of these route changes > > would be greatly appreciated. > > > > > > Thanks, > > > > The kernel uses the routing table to store things like PMTU discovery > data and ARP entries, > Also showing the route -n monitor output will help to identify what is going on. -- :wq Claudio
Re: Unknown process modifying routing table
I've disabled my VPN on the machine as well as dhclient, connecting via a fixed static IP address and DNS servers. My routing table is still being modifed by PID 0 (which I assume to be the kernel) every 30 minutes or so. Ntpd is also disabled. I have also caught my machine communicating to one the of the IPs via TCP and have a pcap dump from wireshark. No actual data was sent other than a TCP timestamp. If your default route is a VPN, please show how you establish the VPN to be your default route. The default route is established mannually in a script that is run after the VPN starts. Essentially it does the following: route add $VPN_HOST $DEFAULT_GW route change default $VPN_HOST I do not belive the VPN to be the cause of this problem. Any tips on debugging the kernel to track the cause of these route changes would be greatly appreciated. Thanks,
Re: Unknown process modifying routing table
On Sat, Feb 06, 2021 at 12:18:40PM +, James wrote: > I've disabled my VPN on the machine as well as dhclient, connecting via a > fixed static IP address and DNS servers. My routing table is still being > modifed by PID 0 (which I assume to be the kernel) every 30 minutes or so. > Ntpd is also disabled. > > I have also caught my machine communicating to one the of the IPs via TCP > and have a pcap dump from wireshark. No actual data was sent other than a > TCP timestamp. > > > If your default route is a VPN, > > please show how you establish the VPN to be your default route. > > > The default route is established mannually in a script that is run after the > VPN starts. Essentially it does the following: > > route add $VPN_HOST $DEFAULT_GW > > route change default $VPN_HOST > > > I do not belive the VPN to be the cause of this problem. > > > Any tips on debugging the kernel to track the cause of these route changes > would be greatly appreciated. > > > Thanks, > The kernel uses the routing table to store things like PMTU discovery data and ARP entries, -Otto
Re: Unknown process modifying routing table
On Jan 26 15:10:03, ja...@jmp-e.com wrote: > > Hi all, > > My routing table is being modified by an unknown process. > > I have system accounting enabled and I'm monitoring route changes > but the PID of the process reported by `route monitor` is always 0 > for these unknown changes. > > I've seen my default route (VPN) being deleted and new routes being > added for specific IPs. I'm out of ideas how to find out what process > is modifying my routing table. If your default route is a VPN, please show how you establish the VPN to be your default route. > Here are the logs: > > bash-5.0# route -n show > Routing tables > > Internet: > DestinationGatewayFlags Refs Use Mtu Prio Iface > default10.0.0.1 UGS 15 635 - 8 pair1 > 224/4 127.0.0.1 URS00 32768 8 lo0 > 10.0.0/24 10.0.0.2 UCn10 - 4 pair1 > 10.0.0.1 xx:xx:xx:xx:xx:xx UHLch 20 76 - 3 pair1 > 10.0.0.2 xx:xx:xx:xx:xx:xx UHLl 0 251 - 1 pair1 > 10.0.0.255 10.0.0.2 UHb00 - 1 pair1 > 10.2.0.1 10.0.0.1 UGHD 1 599 - L 8 pair1 > 13.35.193.117 10.0.0.1 UGHD 1 616 - L 8 pair1 > 13.224.227.64 10.0.0.1 UGHD 1 611 - L 8 pair1 > 52.48.109.111 10.0.0.1 UGHD 1 614 - L 8 pair1 > 52.84.91.7 10.0.0.1 UGHD 1 574 - L 8 pair1 > 99.84.5.23010.0.0.1 UGHD 1 620 - L 8 pair1 > 104.16.9.251 10.0.0.1 UGHD 0 289 1350 8 pair1 > 104.16.241.18 10.0.0.1 UGHD 1 610 - L 8 pair1 > 104.18.26.20 10.0.0.1 UGHD 1 609 - L 8 pair1 > 104.21.22.28 10.0.0.1 UGHD 1 617 - L 8 pair1 > 108.177.120.13610.0.0.1 UGHD 1 625 - L 8 pair1 > 127/8 127.0.0.1 UGRS 00 32768 8 lo0 > 127.0.0.1 127.0.0.1 UHhl 8 7322 32768 1 lo0 > 140.82.121.3 10.0.0.1 UGHD 1 636 - L 8 pair1 > 142.250.186.12910.0.0.1 UGHD 1 604 - L 8 pair1 > 157.230.120.63 10.0.0.1 UGHD 1 596 - L 8 pair1 > 172.67.203.118 10.0.0.1 UGHD 1 607 - L 8 pair1 > 172.217.169.86 10.0.0.1 UGHD 1 632 - L 8 pair1 > 185.199.111.15410.0.0.1 UGHD 2 633 - L 8 pair1 > 216.58.206.132 10.0.0.1 UGHD 1 624 - L 8 pair1 > 216.58.212.227 10.0.0.1 UGHD 1 629 - L 8 pair1 > The routes for 216.58.212.227, 216.58.206.132, 185.199.111.154, > 172.217.169.86, 172.67.203.118, 157.230.120.63, 142.250.186.129, > 140.82.121.3, 108.177.120.136, 104.21.22.28, 104.18.26.20, > 104.16.241.18, 104.16.9.251, 99.84.5.230, 52.48.109.111, 52.84.5.230, > 13.224.227.64, 13.35.193.117 are completely unknown and not added by > myself. These are probably added by your VPN setup. Jan
Re: unknown hostname on ssh tunnel end causes 'administratively prohibited: open failed'
> The code in sshd where the response is composed doesn't know what the
> reason for the failure is. I suspect thid dates back to the original
> Protocol 1 code becuase Protocol 1 didn't (I think) have a reason field.
> This passes the reason back up the stack and sends it to the client.
Sorry for delay, I can't reproduce previous behaviour with your diff.
(Used host is incorrectly non-resolvable via socks5 tunnel.)
But, is following output OK (see '')?
j.
$ ssh -vvv -D localhost
OpenSSH_7.3, LibreSSL 2.5.1
...
Authenticated to localhost ([127.0.0.1]:22).
debug1: Local connections to LOCALHOST: forwarded to remote address socks:0
debug3: channel_setup_fwd_listener_tcpip: type 2 wildcard 0 addr NULL
debug1: Local forwarding listening on 127.0.0.1 port .
...
debug1: Connection to port forwarding to socks port 0 requested.
debug2: fd 10 setting TCP_NODELAY
debug3: fd 10 is O_NONBLOCK
debug3: fd 10 is O_NONBLOCK
debug1: channel 3: new [dynamic-tcpip]
debug2: channel 3: pre_dynamic: have 0
debug2: channel 3: pre_dynamic: have 3
debug2: channel 3: decode socks5
debug2: channel 3: socks5 auth done
debug2: channel 3: pre_dynamic: need more
debug2: channel 3: pre_dynamic: have 0
debug2: channel 3: pre_dynamic: have 45
debug2: channel 3: decode socks5
debug2: channel 3: socks5 post auth
debug2: channel 3: dynamic request: socks5 host
jbelka-vm3.rhev.lab.eng.brq.example.com port 443 command 1
debug3: send packet: type 90
debug3: receive packet: type 92
channel 3: open failed: connect failed: no address associated with name
?
debug2: channel 3: zombie
debug2: channel 3: garbage collecting
debug1: channel 3: free: direct-tcpip: listening port for
jbelka-vm3.rhev.lab.eng.brq.example.com port 443, connect from 127.0.0.1 port
10407 to 127.0.0.1 port , nchannels 4
debug3: channel 3: status: The following connections are open:
#2 client-session (t4 r0 i0/0 o0/0 fd 7/8 cc -1)
debug1: Connection to port forwarding to socks port 0 requested.
debug2: fd 10 setting TCP_NODELAY
debug3: fd 10 is O_NONBLOCK
debug3: fd 10 is O_NONBLOCK
...
Re: unknown hostname on ssh tunnel end causes 'administratively prohibited: open failed'
On Wed, Nov 23, 2016 at 01:35:17PM -0500, Jiri B wrote:
> I was using ssh socks5 tunnel (-D) today and I saw many:
>
> channel 4: open failed: administratively prohibited: open failed
>
> messages. It seems non-resolvable hostnames on my gw (ie. end of ssh
> socks5 tunnel) is passed to client as "prohibited" event.
>
> This seems odd and confusing. GW is an older 6.0-current amd64.
The code in sshd where the response is composed doesn't know what the
reason for the failure is. I suspect thid dates back to the original
Protocol 1 code becuase Protocol 1 didn't (I think) have a reason field.
This passes the reason back up the stack and sends it to the client.
Index: channels.c
===
RCS file: /cvs/src/usr.bin/ssh/channels.c,v
retrieving revision 1.356
diff -u -p -r1.356 channels.c
--- channels.c 18 Oct 2016 17:32:54 - 1.356
+++ channels.c 24 Nov 2016 04:36:58 -
@@ -3038,7 +3038,7 @@ channel_input_port_open(int type, u_int3
}
packet_check_eom();
c = channel_connect_to_port(host, host_port,
- "connected socket", originator_string);
+ "connected socket", originator_string, NULL, NULL);
free(originator_string);
free(host);
if (c == NULL) {
@@ -3995,7 +3995,8 @@ channel_connect_ctx_free(struct channel_
/* Return CONNECTING channel to remote host:port or local socket path */
static Channel *
-connect_to(const char *name, int port, char *ctype, char *rname)
+connect_to(const char *name, int port, char *ctype, char *rname, int *reason,
+char **errmsg)
{
struct addrinfo hints;
int gaierr;
@@ -4036,7 +4037,12 @@ connect_to(const char *name, int port, c
hints.ai_family = IPv4or6;
hints.ai_socktype = SOCK_STREAM;
snprintf(strport, sizeof strport, "%d", port);
- if ((gaierr = getaddrinfo(name, strport, &hints, &cctx.aitop))
!= 0) {
+ if ((gaierr = getaddrinfo(name, strport, &hints, &cctx.aitop))
+ != 0) {
+ if (errmsg != NULL)
+ *errmsg = ssh_gai_strerror(gaierr);
+ if (reason != NULL)
+ *reason = SSH2_OPEN_CONNECT_FAILED;
error("connect_to %.100s: unknown host (%s)", name,
ssh_gai_strerror(gaierr));
return NULL;
@@ -4076,7 +4082,8 @@ channel_connect_by_listen_address(const
return permitted_opens[i].downstream;
return connect_to(
permitted_opens[i].host_to_connect,
- permitted_opens[i].port_to_connect, ctype, rname);
+ permitted_opens[i].port_to_connect, ctype, rname,
+ NULL, NULL);
}
}
error("WARNING: Server requests forwarding for unknown listen_port %d",
@@ -4093,7 +4100,8 @@ channel_connect_by_listen_path(const cha
if (open_listen_match_streamlocal(&permitted_opens[i], path)) {
return connect_to(
permitted_opens[i].host_to_connect,
- permitted_opens[i].port_to_connect, ctype, rname);
+ permitted_opens[i].port_to_connect, ctype, rname,
+ NULL, NULL);
}
}
error("WARNING: Server requests forwarding for unknown path %.100s",
@@ -4103,7 +4111,8 @@ channel_connect_by_listen_path(const cha
/* Check if connecting to that port is permitted and connect. */
Channel *
-channel_connect_to_port(const char *host, u_short port, char *ctype, char
*rname)
+channel_connect_to_port(const char *host, u_short port, char *ctype,
+char *rname, int *reason, char **errmsg)
{
int i, permit, permit_adm = 1;
@@ -4128,9 +4137,10 @@ channel_connect_to_port(const char *host
if (!permit || !permit_adm) {
logit("Received request to connect to host %.100s port %d, "
"but the request was denied.", host, port);
+ *reason = SSH2_OPEN_ADMINISTRATIVELY_PROHIBITED;
return NULL;
}
- return connect_to(host, port, ctype, rname);
+ return connect_to(host, port, ctype, rname, reason, errmsg);
}
/* Check if connecting to that path is permitted and connect. */
@@ -4162,7 +4172,7 @@ channel_connect_to_path(const char *path
"but the request was denied.", path);
return NULL;
}
- return connect_to(path, PORT_STREAMLOCAL, ctype, rname);
+ return connect_to(path, PORT_STREAMLOCAL, ctype, rname, NULL, NULL);
}
void
Index: channels.h
===
RCS file: /cvs/src/usr.bin/ssh/channels.h,v
retrieving revision 1.120
diff -u -p -r1
Re: unknown ethernet: intel dual-port gig copper
Jim Rowan [j...@computing.com] wrote: > > That's really odd... I cut/paste that line directly from the serial > console.. I don't know how it got to be showing 0x8096 instead of 0x8086. > > Sorry for the false alarm! (I'll still have to track down what's wrong > with flashrd... as I want to use it.) Growing the GENERIC kernel (such as by adding a ramdisk) can write beyond the intended area. Raising NKPTP on i386 isn't always enough. I don't understand the problem well enough to provide an immediate solution. It has been a while since I've seen problems on i386 or amd64, but GENERIC keeps getting bigger :) Chris
Re: unknown ethernet: intel dual-port gig copper
On Oct 25, 2014, at 9:47 PM, Jonathan Gray wrote: On Sat, Oct 25, 2014 at 07:35:46PM -0500, Jim Rowan wrote: Hi, On 5.6 (I haven't tried this with anything older yet) my network card isn't recognized. It's an intel dual-port gig-e card. unknown vendor 0x8096 product 0x1010 (class network subclass ethernet, rev 0x11) at pci0 dev 8 function 0 not configured Can I do something to use this card? I can't find any mention of any other Intel device with a 0x8096 vendor id. 0x8086 0x1010 is 82546EB Copper, what does the chip have printed on it? That's what it is. I had been using the flashrd 5.6 image earlier.. and apparently this weirdness has something to do with that. Booting from a fresh 5.5 install recognizes it properly and shows this message: em0 at pci0 dev 8 function 0 "Intel 82546EB" rev 0x01: irq 11, address 00:11:0a:5f:eb:34 em1 at pci0 dev 8 function 1 "Intel 82546EB" rev 0x01: irq 10, address 00:11:0a:5f:eb:35 That's really odd... I cut/paste that line directly from the serial console.. I don't know how it got to be showing 0x8096 instead of 0x8086. Sorry for the false alarm! (I'll still have to track down what's wrong with flashrd... as I want to use it.)
Re: unknown ethernet: intel dual-port gig copper
On Sat, Oct 25, 2014 at 07:35:46PM -0500, Jim Rowan wrote: > Hi, > > On 5.6 (I haven't tried this with anything older yet) my network card > isn't recognized. It's an intel dual-port gig-e card. > > unknown vendor 0x8096 product 0x1010 (class network subclass ethernet, > rev 0x11) at pci0 dev 8 function 0 not configured > > Can I do something to use this card? I can't find any mention of any other Intel device with a 0x8096 vendor id. 0x8086 0x1010 is 82546EB Copper, what does the chip have printed on it?
Re: Unknown bgp issue
If you were trying to ping both of your BGP peers (and failing), I'm guessing both are on directly connected subnets as per eBGP rules. As they are directly connected, routing protocols shouldn't have been an issue so it was probably the firewall. If I remember correctly, if you block outbound pings you get a 'no route to host'. So it sounds like it could have been a PF resource problem. Do you run PF and how many states do you have usually? On Sat 12 Apr 2014 18:54:11 BST, Randhir Prakash wrote: Hi, I have been using Openbgpd on Openbsd from last 3 years without any issue. We are having two upstream providers with full route. Suddenly last week, i observed that our network became unreachable from internet and sometimes fluctuating in terms of reachability. I checked the bgp session using bgpctl show summary which was showing bgp session alive and PrfRcvd(Received prefix) from our peers was fine. When i tried to ping to both peers WAN IP or any inetrnet ip, it was telling "no route to host". When i connected peers wan ip to standalone system and tried pinging, it was pinging. I was not able to figure out the issue and after 45-60 minutes, automatically everything got rectified and became normal. I am not having any idea about this issue and want to explore to avoid such situations in production environment. Kindly assist.
Re: pf faq [was Re: (unknown)]
On Sat, May 26, 2012 at 9:30 AM, Stuart Henderson wrote: > On 2012-05-26, Jan Stary wrote: >> The "Passing Traffic" example at >> http://www.openbsd.org/faq/pf/filter.html >> doesn't seem to be completely accurate. >> >> # Pass traffic in on dc0 from the local network, 192.168.0.0/24, >> # to the OpenBSD machine's IP address 192.168.0.1. Also, pass the >> # return traffic out on dc0. >> pass in on dc0 from 192.168.0.0/24 to 192.168.0.1 >> pass out on dc0 from 192.168.0.1 to 192.168.0.0/24 >> >> It's the "return" that bugs me: the first rule alone >> makes the _return_ traffic be passed. The second >> rule allows traffic that originates (creates state) >> on the way out. Right? >> >> > > Probably an incomplete conversion of the faq when the default was changed > to stateful. If someone wants to carefully go over faq/pf/ (or at least going > over one whole page rather than just parts of a page), check/update things > and send a diff, that would be very nice and there's a good chance it would > get committed.. > It allows the router (or other machines not in the network) to reach others computer in the network, and I'm not sure if without that rule you would be able to do ssh 192.168.0.10 to 192.168.0.20 (sine you only got a state 192.168.0.10->192.168.0.1 and not 192.168.0.1->192.168.0.20). It allows for an instance: you want to reach your machine remotely that is behind the firewall 192.168.0.1, you do: 1 - ssh to your router or some machine that the router translates its ip to it. 2 - Access your machine inside the network without nat-ing direct access to it.
pf faq [was Re: (unknown)]
On 2012-05-26, Jan Stary wrote: > The "Passing Traffic" example at > http://www.openbsd.org/faq/pf/filter.html > doesn't seem to be completely accurate. > > # Pass traffic in on dc0 from the local network, 192.168.0.0/24, > # to the OpenBSD machine's IP address 192.168.0.1. Also, pass the > # return traffic out on dc0. > pass in on dc0 from 192.168.0.0/24 to 192.168.0.1 > pass out on dc0 from 192.168.0.1 to 192.168.0.0/24 > > It's the "return" that bugs me: the first rule alone > makes the _return_ traffic be passed. The second > rule allows traffic that originates (creates state) > on the way out. Right? > > Probably an incomplete conversion of the faq when the default was changed to stateful. If someone wants to carefully go over faq/pf/ (or at least going over one whole page rather than just parts of a page), check/update things and send a diff, that would be very nice and there's a good chance it would get committed..
Re: Unknown error: code 60 installing OpenBSD/macppc in iMac G3
On 11/03/12(Sun) 20:27, Daniel Bolgheroni wrote: > Hi misc@, > > tired of using these crap CD-ROM units, I've decided to give it a try > booting from a TFTP server, to install OpenBSD/macppc on one of the > iMacs I have here. > > I configured tftpd running on a OpenBSD/amd64 machine according to > section 6.10 of the FAQ, with the needed files. You'll need a nfs server for booting a macppc. > > So, here is what I have: > > 0 > boot enet:,ofwboot /bsd.rd > CLIENT: 000a27d6afae 192.168.1.32 > SERVER: 001b242e5ce6 192.168.1.7 > Transfer FILE ofwboot \ > TFTP-actual=fe88 TFTP-adler32=2e938515 load-size=fe88 adler32=2e938515 > > Loading ELF > >> OpenBSD/macppc BOOT 1.2 > open(/pci@f400/ethernet:/etc/boot.conf): Unknown error: code 60 > boot> > > After this, the same error repeats trying /bsd.rd, /bsd, etc. > > Anyone has any clues on this? I really don't want to ever touch an > optical driver again. You should have a look at INSTALL.macppc [0], it says: boot enet:,ofwboot /bsd.rd (netboot from a pre-configured dhcp/tftp/nfs server; "ofwboot" will be obtained from the tftp server, while "bsd.rd" will be obtained from the NFS server, as specified by the "next-server" and "root-path" dhcp options) Martin [0] ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/macppc/INSTALL.macppc
Re: Unknown error: code 60 installing OpenBSD/macppc in iMac G3
>tired of using these crap CD-ROM units, I've decided to give it a try >booting from a TFTP server, to install OpenBSD/macppc on one of the >iMacs I have here. > >I configured tftpd running on a OpenBSD/amd64 machine according to >section 6.10 of the FAQ, with the needed files. > >So, here is what I have: > >0 > boot enet:,ofwboot /bsd.rd >CLIENT: 000a27d6afae 192.168.1.32 >SERVER: 001b242e5ce6 192.168.1.7 >Transfer FILE ofwboot \ >TFTP-actual=fe88 TFTP-adler32=2e938515 load-size=fe88 adler32=2e938515 > >Loading ELF >>> OpenBSD/macppc BOOT 1.2 >open(/pci@f400/ethernet:/etc/boot.conf): Unknown error: code 60 >boot> > >After this, the same error repeats trying /bsd.rd, /bsd, etc. > >Anyone has any clues on this? I really don't want to ever touch an >optical driver again. In almost all cases where we print an "error" number, it is an errno from /sys/sys/errno.h. We'd print it by the prober name for the error, but there is no room on the bootblocks for that table. Here's the error: #define ETIMEDOUT 60 /* Operation timed out */ Likely this means that you have not setup some service that the bootloader needs for filesystem access. Different bootloaders have different network file system requirements -- check diskless(8) for more information.
Re: Unknown COM to PCMCIA adapter, some help?
2011/10/9 Jonathan Gray > On Sun, Oct 09, 2011 at 03:28:49PM +0300, Atanas Vladimirov wrote: > > 2011/10/9 Jonathan Gray > > > > > On Sun, Oct 09, 2011 at 12:02:03PM +0300, Atanas Vladimirov wrote: > > > > > > > > How can I do that? Can you show me an example of the command I need? > > > > > > yes, plug the card in and send me the full output of "pcidump -v" > > > run as root, without removing any parts of the output. > > > > > > thanks > > > > > > > Here you go: > > oops my mistake, we don't print anything for cardbus cards yet as we > still treat it as a seperate set of abstractions from pci. > That's why I coudn't see it at the first time. :) OK. What's up next? Do You need more information?
Re: Unknown COM to PCMCIA adapter, some help?
On Sun, Oct 09, 2011 at 03:28:49PM +0300, Atanas Vladimirov wrote: > 2011/10/9 Jonathan Gray > > > On Sun, Oct 09, 2011 at 12:02:03PM +0300, Atanas Vladimirov wrote: > > > > > > How can I do that? Can you show me an example of the command I need? > > > > yes, plug the card in and send me the full output of "pcidump -v" > > run as root, without removing any parts of the output. > > > > thanks > > > > Here you go: oops my mistake, we don't print anything for cardbus cards yet as we still treat it as a seperate set of abstractions from pci.
Re: Unknown COM to PCMCIA adapter, some help?
2011/10/9 Jonathan Gray > On Sun, Oct 09, 2011 at 12:02:03PM +0300, Atanas Vladimirov wrote: > > > > How can I do that? Can you show me an example of the command I need? > > yes, plug the card in and send me the full output of "pcidump -v" > run as root, without removing any parts of the output. > > thanks > Here you go: # pcidump -v Domain /dev/pci0: 0:0:0: Intel 82945GM Host 0x: Vendor ID: 8086 Product ID: 27a0 0x0004: Command: 0106 Status ID: 2090 0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 03 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 17aa Product ID: 2015 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0x00e0: Capability 0x09: Vendor Specific 0:1:0: Intel 82945GM PCIE 0x: Vendor ID: 8086 Product ID: 27a1 0x0004: Command: 0107 Status ID: 0010 0x0008: Class: 06 Subclass: 04 Interface: 00 Revision: 03 0x000c: BIST: 00 Header Type: 01 Latency Timer: 00 Cache Line Size: 10 0x0010: 0x0014: 0x0018: Primary Bus: 0 Secondary Bus: 1 Subordinate Bus: 1 Secondary Latency Timer: 00 0x001c: I/O Base: 20 I/O Limit: 20 Secondary Status: 2000 0x0020: Memory Base: ee10 Memory Limit: ee10 0x0024: Prefetch Memory Base: d801 Prefetch Memory Limit: dff1 0x0028: Prefetch Memory Base Upper 32 Bits: 0x002c: Prefetch Memory Limit Upper 32 Bits: 0x0030: I/O Base Upper 16 Bits: I/O Limit Upper 16 Bits: 0x0038: Expansion ROM Base Address: 0x003c: Interrupt Pin: 01 Line: 0b Bridge Control: 001c 0x0088: Capability 0x0d: PCI-PCI 0x0080: Capability 0x01: Power Management 0x0090: Capability 0x05: Message Signaled Interrupts (MSI) 0x00a0: Capability 0x10: PCI Express Link Speed: 2.5 / 2.5 Gb/s Link Width: x16 / x16 0:27:0: Intel 82801GB HD Audio 0x: Vendor ID: 8086 Product ID: 27d8 0x0004: Command: 0106 Status ID: 0010 0x0008: Class: 04 Subclass: 03 Interface: 00 Revision: 02 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 10 0x0010: BAR mem 64bit addr: 0xee40/0x4000 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 17aa Product ID: 2010 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 02 Line: 0b Min Gnt: 00 Max Lat: 00 0x0050: Capability 0x01: Power Management 0x0060: Capability 0x05: Message Signaled Interrupts (MSI) 0x0070: Capability 0x10: PCI Express 0:28:0: Intel 82801GB PCIE 0x: Vendor ID: 8086 Product ID: 27d0 0x0004: Command: 0107 Status ID: 0010 0x0008: Class: 06 Subclass: 04 Interface: 00 Revision: 02 0x000c: BIST: 00 Header Type: 81 Latency Timer: 00 Cache Line Size: 10 0x0010: 0x0014: 0x0018: Primary Bus: 0 Secondary Bus: 2 Subordinate Bus: 2 Secondary Latency Timer: 00 0x001c: I/O Base: 30 I/O Limit: 30 Secondary Status: 2000 0x0020: Memory Base: ee00 Memory Limit: ee00 0x0024: Prefetch Memory Base: fff1 Prefetch Memory Limit: 0001 0x0028: Prefetch Memory Base Upper 32 Bits: 0x002c: Prefetch Memory Limit Upper 32 Bits: 0x0030: I/O Base Upper 16 Bits: I/O Limit Upper 16 Bits: 0x0038: Expansion ROM Base Address: 0x003c: Interrupt Pin: 01 Line: 0b Bridge Control: 0004 0x0040: Capability 0x10: PCI Express Link Speed: 2.5 / 2.5 Gb/s Link Width: x1 / x1 0x0080: Capability 0x05: Message Signaled Interrupts (MSI) 0x0090: Capability 0x0d: PCI-PCI 0x00a0: Capability 0x01: Power Management 0:28:1: Intel 82801GB PCIE 0x: Vendor ID: 8086 Product ID: 27d2 0x0004: Command: 0107 Status ID: 0010 0x0008: Class: 06 Subclass: 04 Interface: 00 Revision: 02 0x000c: BIST: 00 Header Type: 81 Latency Timer: 00 Cache Line Size: 10 0x0010: 0x0014: 0x0018: Primary Bus: 0 Secondary Bus: 3 Subordinate Bus: 3 Secondary Latency Timer: 00 0x001c: I/O Base: 40 I/O Limit: 50 Secondary Status: 2000 0x0020: Memory Base: ec00 Memory Limit: edf0 0x0024: Prefetch Memory Base: e401 Prefetch Memory Limit: e401 0x0028: Prefetch Memory Base Upper 32 Bits: 0x002c: Prefetch Memory Limit Upper 32 Bits: 0x0030: I/O Base Upper 16 Bits: I/O Limit Upper 16 Bits: 0x0038: Expansion ROM Base Address: 0x003c: Interrupt Pin: 02 Line: 0b Bridge Control: 0004 0x0040: Capability 0x10: PCI Express Link Speed: 2.5 / 2.5 Gb/s Link Width: x1 / x1 0x0080: Capability 0x05: Message Signaled Interrupts (MSI) 0x0090: Capability 0x0d: PCI-PCI 0x00a0: Capability 0x01: Power Management 0:28:2: Intel 82801GB PCIE 0x: Vendor ID: 8086 Product ID: 27d4 0x0004: Command: 0107 Status ID: 0010 0x0008: Class: 06 Subclass: 04
Re: Unknown COM to PCMCIA adapter, some help?
2011/10/9 Jonathan Gray
> On Sat, Oct 08, 2011 at 09:06:15PM +0300, Atanas Vladimirov wrote:
> > 2011/10/8 Jonathan Gray
> >
> > > On Sat, Oct 08, 2011 at 01:35:19PM +0300, Atanas Vladimirov wrote:
> > > > Hi misc,
> > > >
> > > > Recently I bought COM to PCMCIA adapter, full dmesg at end of e-mail.
> > > > I don't understand programming and I can't offer working patches, but
> I
> > > can
> > > > test patches.
> > > > Tell me if I can give more information, that would be useful.
> > > > Sorry for my english, and sorry if I send to wrong mailing list.
> > > >
> > > > Try it with the last snapshot from Oct 7 2011 and it was not
> configured:
> > > > unknown vendor 0x4348 product 0x3253 (class communications subclass
> > > serial,
> > > > rev 0x10) at cardbus0 dev 0 function 0 not configured
> > >
> > > try this, it doesn't include pcidevs information to make it easier to
> apply
> > >
> > > It would also be helpful if you could include the output of "pcidump
> -v"
> > >
> > > Index: sys/dev/cardbus/com_cardbus.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/cardbus/com_cardbus.c,v
> > > retrieving revision 1.40
> > > diff -u -p -r1.40 com_cardbus.c
> > > --- sys/dev/cardbus/com_cardbus.c 15 Nov 2010 23:19:34 -
> > > 1.40
> > > +++ sys/dev/cardbus/com_cardbus.c 8 Oct 2011 12:56:40 -
> > > @@ -125,6 +125,8 @@ static struct csdev {
> > >{ PCI_VENDOR_XIRCOM, PCI_PRODUCT_XIRCOM_CBEM56G,
> > > CARDBUS_BASE0_REG, PCI_MAPREG_TYPE_IO },
> > >{ PCI_VENDOR_XIRCOM, PCI_PRODUCT_XIRCOM_MODEM56,
> > > + CARDBUS_BASE0_REG, PCI_MAPREG_TYPE_IO },
> > > + { 0x4348, 0x3253,
> > > CARDBUS_BASE0_REG, PCI_MAPREG_TYPE_IO }
> > > };
> > >
> > > Index: sys/dev/pci/pucdata.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/pci/pucdata.c,v
> > > retrieving revision 1.74
> > > diff -u -p -r1.74 pucdata.c
> > > --- sys/dev/pci/pucdata.c 20 Apr 2011 04:58:29 - 1.74
> > > +++ sys/dev/pci/pucdata.c 8 Oct 2011 12:56:41 -
> > > @@ -1734,6 +1734,14 @@ const struct puc_device_description puc_
> > >{ PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ },
> > >},
> > >},
> > > + { /* "WinChipHead CH352", */
> > > + { 0x4348, 0x3253, 0, 0},
> > > + { 0x, 0x, 0, 0
> },
> > > + {
> > > + { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ },
> > > + { PUC_PORT_TYPE_COM, 0x14, 0x00, COM_FREQ },
> > > + },
> > > + },
> > >
> > >{ /* NULL, */
> > >
> > >
> > Thanks for your respond. I coudn't apply your patch. I tried with
> > # cd /usr/src
> > # patch -p0 < /path/to/patch
> > But I got errors. After that I manualy edited the two files and made the
> > following patch, which works great.
> > Then I compiled the new kernel. Full dmesg at the end of e-mail.
> > Now pcmcia adapter works fine. I made two tests, one at 4800 baud and
> other
> > at 115200 baud, there were no errors.
> >
> > com3 at cardbus0 dev 0 function 0 unknown vendor 0x4348 product 0x3253
> rev
> > 0x10: irq 268505099: ns16550a, 16 byte fifo
> >
> > # pcidump -v (when pcmcia adapter was pluged in)
>
> Can you show the pcidump entries from the serial card itself here?
>
How can I do that? Can you show me an example of the command I need?
> The point of interest is how many BARs it has.
>
> The chip is apparently at least a two port device, how
> many ports does your card have?
>
Yes, the chip is two port device, but my card has only one rs-232 port.
When I installed the card under windows, it shows two COM ports in windows
device manager, but only one works.
I bougth it from
here.
[
http://www.ebay.com/itm/RS232-DB9-Serial-Port-PCMCIA-PC-Card-CardBus-Adapter-/180726917544?pt=LH_DefaultDomain_0&hash=item2a1429e9a8#ht_2820wt_908
]
Thanks for your help.
Re: Unknown COM to PCMCIA adapter, some help?
On Sat, Oct 08, 2011 at 09:06:15PM +0300, Atanas Vladimirov wrote:
> 2011/10/8 Jonathan Gray
>
> > On Sat, Oct 08, 2011 at 01:35:19PM +0300, Atanas Vladimirov wrote:
> > > Hi misc,
> > >
> > > Recently I bought COM to PCMCIA adapter, full dmesg at end of e-mail.
> > > I don't understand programming and I can't offer working patches, but I
> > can
> > > test patches.
> > > Tell me if I can give more information, that would be useful.
> > > Sorry for my english, and sorry if I send to wrong mailing list.
> > >
> > > Try it with the last snapshot from Oct 7 2011 and it was not configured:
> > > unknown vendor 0x4348 product 0x3253 (class communications subclass
> > serial,
> > > rev 0x10) at cardbus0 dev 0 function 0 not configured
> >
> > try this, it doesn't include pcidevs information to make it easier to apply
> >
> > It would also be helpful if you could include the output of "pcidump -v"
> >
> > Index: sys/dev/cardbus/com_cardbus.c
> > ===
> > RCS file: /cvs/src/sys/dev/cardbus/com_cardbus.c,v
> > retrieving revision 1.40
> > diff -u -p -r1.40 com_cardbus.c
> > --- sys/dev/cardbus/com_cardbus.c 15 Nov 2010 23:19:34 -
> > 1.40
> > +++ sys/dev/cardbus/com_cardbus.c 8 Oct 2011 12:56:40 -
> > @@ -125,6 +125,8 @@ static struct csdev {
> >{ PCI_VENDOR_XIRCOM, PCI_PRODUCT_XIRCOM_CBEM56G,
> > CARDBUS_BASE0_REG, PCI_MAPREG_TYPE_IO },
> >{ PCI_VENDOR_XIRCOM, PCI_PRODUCT_XIRCOM_MODEM56,
> > + CARDBUS_BASE0_REG, PCI_MAPREG_TYPE_IO },
> > + { 0x4348, 0x3253,
> > CARDBUS_BASE0_REG, PCI_MAPREG_TYPE_IO }
> > };
> >
> > Index: sys/dev/pci/pucdata.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/pucdata.c,v
> > retrieving revision 1.74
> > diff -u -p -r1.74 pucdata.c
> > --- sys/dev/pci/pucdata.c 20 Apr 2011 04:58:29 - 1.74
> > +++ sys/dev/pci/pucdata.c 8 Oct 2011 12:56:41 -
> > @@ -1734,6 +1734,14 @@ const struct puc_device_description puc_
> >{ PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ },
> >},
> >},
> > + { /* "WinChipHead CH352", */
> > + { 0x4348, 0x3253, 0, 0},
> > + { 0x, 0x, 0, 0},
> > + {
> > + { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ },
> > + { PUC_PORT_TYPE_COM, 0x14, 0x00, COM_FREQ },
> > + },
> > + },
> >
> >{ /* NULL, */
> >
> >
> Thanks for your respond. I coudn't apply your patch. I tried with
> # cd /usr/src
> # patch -p0 < /path/to/patch
> But I got errors. After that I manualy edited the two files and made the
> following patch, which works great.
> Then I compiled the new kernel. Full dmesg at the end of e-mail.
> Now pcmcia adapter works fine. I made two tests, one at 4800 baud and other
> at 115200 baud, there were no errors.
>
> com3 at cardbus0 dev 0 function 0 unknown vendor 0x4348 product 0x3253 rev
> 0x10: irq 268505099: ns16550a, 16 byte fifo
>
> # pcidump -v (when pcmcia adapter was pluged in)
Can you show the pcidump entries from the serial card itself here?
The point of interest is how many BARs it has.
The chip is apparently at least a two port device, how
many ports does your card have?
> ..
> 21:0:0: TI PCI1510 CardBus
Re: Unknown COM to PCMCIA adapter, some help?
2011/10/8 Jonathan Gray
> On Sat, Oct 08, 2011 at 01:35:19PM +0300, Atanas Vladimirov wrote:
> > Hi misc,
> >
> > Recently I bought COM to PCMCIA adapter, full dmesg at end of e-mail.
> > I don't understand programming and I can't offer working patches, but I
> can
> > test patches.
> > Tell me if I can give more information, that would be useful.
> > Sorry for my english, and sorry if I send to wrong mailing list.
> >
> > Try it with the last snapshot from Oct 7 2011 and it was not configured:
> > unknown vendor 0x4348 product 0x3253 (class communications subclass
> serial,
> > rev 0x10) at cardbus0 dev 0 function 0 not configured
>
> try this, it doesn't include pcidevs information to make it easier to apply
>
> It would also be helpful if you could include the output of "pcidump -v"
>
> Index: sys/dev/cardbus/com_cardbus.c
> ===
> RCS file: /cvs/src/sys/dev/cardbus/com_cardbus.c,v
> retrieving revision 1.40
> diff -u -p -r1.40 com_cardbus.c
> --- sys/dev/cardbus/com_cardbus.c 15 Nov 2010 23:19:34 -
> 1.40
> +++ sys/dev/cardbus/com_cardbus.c 8 Oct 2011 12:56:40 -
> @@ -125,6 +125,8 @@ static struct csdev {
>{ PCI_VENDOR_XIRCOM, PCI_PRODUCT_XIRCOM_CBEM56G,
> CARDBUS_BASE0_REG, PCI_MAPREG_TYPE_IO },
>{ PCI_VENDOR_XIRCOM, PCI_PRODUCT_XIRCOM_MODEM56,
> + CARDBUS_BASE0_REG, PCI_MAPREG_TYPE_IO },
> + { 0x4348, 0x3253,
> CARDBUS_BASE0_REG, PCI_MAPREG_TYPE_IO }
> };
>
> Index: sys/dev/pci/pucdata.c
> ===
> RCS file: /cvs/src/sys/dev/pci/pucdata.c,v
> retrieving revision 1.74
> diff -u -p -r1.74 pucdata.c
> --- sys/dev/pci/pucdata.c 20 Apr 2011 04:58:29 - 1.74
> +++ sys/dev/pci/pucdata.c 8 Oct 2011 12:56:41 -
> @@ -1734,6 +1734,14 @@ const struct puc_device_description puc_
>{ PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ },
>},
>},
> + { /* "WinChipHead CH352", */
> + { 0x4348, 0x3253, 0, 0},
> + { 0x, 0x, 0, 0},
> + {
> + { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ },
> + { PUC_PORT_TYPE_COM, 0x14, 0x00, COM_FREQ },
> + },
> + },
>
>{ /* NULL, */
>
>
Thanks for your respond. I coudn't apply your patch. I tried with
# cd /usr/src
# patch -p0 < /path/to/patch
But I got errors. After that I manualy edited the two files and made the
following patch, which works great.
Then I compiled the new kernel. Full dmesg at the end of e-mail.
Now pcmcia adapter works fine. I made two tests, one at 4800 baud and other
at 115200 baud, there were no errors.
com3 at cardbus0 dev 0 function 0 unknown vendor 0x4348 product 0x3253 rev
0x10: irq 268505099: ns16550a, 16 byte fifo
# pcidump -v (when pcmcia adapter was pluged in)
..
21:0:0: TI PCI1510 CardBus
0x: Vendor ID: 104c Product ID: ac56
0x0004: Command: 0007 Status ID: 0210
0x0008: Class: 06 Subclass: 07 Interface: 00 Revision: 00
0x000c: BIST: 00 Header Type: 02 Latency Timer: a8 Cache Line Size:
08
0x0010: Cardbus Control Registers Base Address: e430
0x0018: Primary Bus: 21 Cardbus Bus: 22 Subordinate Bus: 24
Cardbus Latency Timer: b0
0x001c: Memory Base 0: f000
0x0020: Memory Limit 0:
0x0024: Memory Base 1: f000
0x0028: Memory Limit 1:
0x002c: I/O Base 0: a300
0x0030: I/O Limit 0: a304
0x0034: I/O Base 1: fffc
0x0038: I/O Limit 1:
0x003c: Interrupt Pin: 01 Line: 0b Bridge Control: 0700
0x0040: Subsystem Vendor ID: 17aa Product ID: 2012
0x0044: 16-bit Legacy Mode Base Address: 0001
0x00a0: Capability 0x01: Power Management
# pcidump -v (when pcmcia adapter was ejected)
..
21:0:0: TI PCI1510 CardBus
0x: Vendor ID: 104c Product ID: ac56
0x0004: Command: 0007 Status ID: 0210
0x0008: Class: 06 Subclass: 07 Interface: 00 Revision: 00
0x000c: BIST: 00 Header Type: 02 Latency Timer: a8 Cache Line Size:
08
0x0010: Cardbus Control Registers Base Address: e430
0x0018: Primary Bus: 21 Cardbus Bus: 22 Subordinate Bus: 24
Cardbus Latency Timer: b0
0x001c: Memory Base 0: f000
0x0020: Memory Limit 0:
0x0024: Memory Base 1: f000
0x0028: Memory Limit 1:
0x002c: I/O Base 0: fffc
0x0030: I/O Limit 0:
0x0034: I/O Base 1: fffc
0x0038: I/O Limit 1:
0x003c: Interrupt Pin: 01 Line: 0b Bridge Control: 07c0
0x0040: Subsystem Vendor ID: 17aa Product ID: 2012
0x0044: 16-bit Legacy Mode Base Ad
Re: Unknown COM to PCMCIA adapter, some help?
On Sat, Oct 08, 2011 at 01:35:19PM +0300, Atanas Vladimirov wrote:
> Hi misc,
>
> Recently I bought COM to PCMCIA adapter, full dmesg at end of e-mail.
> I don't understand programming and I can't offer working patches, but I can
> test patches.
> Tell me if I can give more information, that would be useful.
> Sorry for my english, and sorry if I send to wrong mailing list.
>
> Try it with the last snapshot from Oct 7 2011 and it was not configured:
> unknown vendor 0x4348 product 0x3253 (class communications subclass serial,
> rev 0x10) at cardbus0 dev 0 function 0 not configured
try this, it doesn't include pcidevs information to make it easier to apply
It would also be helpful if you could include the output of "pcidump -v"
Index: sys/dev/cardbus/com_cardbus.c
===
RCS file: /cvs/src/sys/dev/cardbus/com_cardbus.c,v
retrieving revision 1.40
diff -u -p -r1.40 com_cardbus.c
--- sys/dev/cardbus/com_cardbus.c 15 Nov 2010 23:19:34 - 1.40
+++ sys/dev/cardbus/com_cardbus.c 8 Oct 2011 12:56:40 -
@@ -125,6 +125,8 @@ static struct csdev {
{ PCI_VENDOR_XIRCOM, PCI_PRODUCT_XIRCOM_CBEM56G,
CARDBUS_BASE0_REG, PCI_MAPREG_TYPE_IO },
{ PCI_VENDOR_XIRCOM, PCI_PRODUCT_XIRCOM_MODEM56,
+ CARDBUS_BASE0_REG, PCI_MAPREG_TYPE_IO },
+ { 0x4348, 0x3253,
CARDBUS_BASE0_REG, PCI_MAPREG_TYPE_IO }
};
Index: sys/dev/pci/pucdata.c
===
RCS file: /cvs/src/sys/dev/pci/pucdata.c,v
retrieving revision 1.74
diff -u -p -r1.74 pucdata.c
--- sys/dev/pci/pucdata.c 20 Apr 2011 04:58:29 - 1.74
+++ sys/dev/pci/pucdata.c 8 Oct 2011 12:56:41 -
@@ -1734,6 +1734,14 @@ const struct puc_device_description puc_
{ PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ },
},
},
+ { /* "WinChipHead CH352", */
+ { 0x4348, 0x3253, 0, 0},
+ { 0x, 0x, 0, 0},
+ {
+ { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ },
+ { PUC_PORT_TYPE_COM, 0x14, 0x00, COM_FREQ },
+ },
+ },
{ /* NULL, */
Re: (unknown)
On 2011-08-25, igor denisov wrote: > Hello there, > > I am going to try to insert additional RAM "TRUMP D1SC0816D DDR > 1GB-333Mhz SO.DIMM" the native RAM is 256MB, and I know for sure when > the additional RAM inserted I have lot of kernel panics and all the > time they are different and occur at different times when PC is ran. Make sure the RAM is compatible with the machine and with the existing RAM (same speed/CAS latency etc.). Have you tried taking out the existing RAM and just using the new RAM? Have you tried different RAM slots? > My question is how to get kernel panics dump to a file for further > investigation? "boot dump", see ddb(4). But it's unlikely to help you here.
Re: (unknown)
On 2010-09-23, Dave Del Debbio wrote: > bridge. Please see how devio.us solved their livelock problem here: people are using the word "livelock" to refer to all sorts of different things
Re: unknown i686 model 0x1e, can't get bus clock (0x0)
On Fri, Jun 04, 2010 at 07:44:21PM +0300, Dexter Tomisson wrote: > On 4 June 2010 14:25, Andreas Gerdd wrote: > > > And should we expect having a better support for Intel Core i5/i7 CPUs > > in the near future, maybe for the next release cycle? > > > > > > > Sounds no; > > Changes by: > > j...@cvs.openbsd.org > > 2010/06/04 09:03:35 > Modified files: > > sys/arch/amd64/amd64: est.c > > sys/arch/i386/i386: machdep.c > Log message: > Don't warn about not knowing what the bus clock is on core i7/i5/i3 > as the high/low guessing won't be done on these processors due to MSR > differences. > > Just 'hide' them. Such a great solution! Look at the code, look at the MSRs, take FSB_FREQ for example, this is not valid on nehalem (no FSB). Take the interpretation of PERF_STATUS using bits that Intel claims are reserved. The ACPI and non ACPI codepaths need to be more isolated from each other and this then needs to be heavily tested. If you were to invest just the smallest of amounts of time looking at how it actually works and the history of the speedstep code you'd understand.
Re: unknown i686 model 0x1e, can't get bus clock (0x0)
* Dexter Tomisson [2010-06-04 18:48]: > On 4 June 2010 14:25, Andreas Gerdd wrote: > > And should we expect having a better support for Intel Core i5/i7 CPUs > > in the near future, maybe for the next release cycle? just check our ever famous public roadmap > Sounds no; > > Changes by: > > j...@cvs.openbsd.org > > 2010/06/04 09:03:35 > Modified files: > > sys/arch/amd64/amd64: est.c > > sys/arch/i386/i386: machdep.c > Log message: > Don't warn about not knowing what the bus clock is on core i7/i5/i3 > as the high/low guessing won't be done on these processors due to MSR > differences. > > Just 'hide' them. Such a great solution! that doesn't mean anything. the info just isn't in the same place as it used to be, so it is pointless for this part of the code to try to figure it out. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: unknown i686 model 0x1e, can't get bus clock (0x0)
On 4 June 2010 14:25, Andreas Gerdd wrote: > And should we expect having a better support for Intel Core i5/i7 CPUs > in the near future, maybe for the next release cycle? > > > Sounds no; Changes by: j...@cvs.openbsd.org 2010/06/04 09:03:35 Modified files: sys/arch/amd64/amd64: est.c sys/arch/i386/i386: machdep.c Log message: Don't warn about not knowing what the bus clock is on core i7/i5/i3 as the high/low guessing won't be done on these processors due to MSR differences. Just 'hide' them. Such a great solution!
Re: unknown i686 model 0x1e, can't get bus clock (0x0)
On Thu, 3 Jun 2010 21:43:48 +0300 Andreas Gerdd wrote: > Would installing OpenBSD/amd64 help to recognize the CPU > (Intel Core i5 750) or make things a bit better? Using OpenBSD/i386 > currently.. 64bit amd64 would make more sense on that hardware, yes. > Do all these alerts mean that i have a decreased CPU performance on > the server > -because of the unrecognized CPU-? no, what is complaining is the speedstep stuff, so your cpu just doesn't clock down from the default speed.
Re: unknown i686 model 0x1e, can't get bus clock (0x0)
On Thu, 3 Jun 2010 18:20:06 +1000 Jonathan Gray wrote: > On Wed, Jun 02, 2010 at 09:39:38PM +0200, Robert wrote: > > On Wed, 2 Jun 2010 13:54:34 +0300 > > "kryptos...@gmail.com " wrote: > > > > > Hi, > > > > > > On OpenBSD 4.7, my dmesg output has the following alerts: > > > > > > cpu1: unknown i686 model 0x1e, can't get bus clock (0x0) > > > cpu2: unknown i686 model 0x1e, can't get bus clock (0x0) > > > cpu3: unknown i686 model 0x1e, can't get bus clock (0x0) > > > > > > Is this a normal alert? Any idea? > > > > For speedstep you need something ___similar___ to this. > > Didn't bother to look up the supported fsbfreqs, just remembered > > something bout 133MHz base clock. (check intel site or code and > > adapt) Atleast this should get you an idea where the love is needed. > > No, the ACPI PSS paths need to be rewritten to use different > MSRs for newer intel processors otherwise bad things will happen. Ok, my bad.
Re: unknown i686 model 0x1e, can't get bus clock (0x0)
On Wed, Jun 02, 2010 at 09:39:38PM +0200, Robert wrote: > On Wed, 2 Jun 2010 13:54:34 +0300 > "kryptos...@gmail.com " wrote: > > > Hi, > > > > On OpenBSD 4.7, my dmesg output has the following alerts: > > > > cpu1: unknown i686 model 0x1e, can't get bus clock (0x0) > > cpu2: unknown i686 model 0x1e, can't get bus clock (0x0) > > cpu3: unknown i686 model 0x1e, can't get bus clock (0x0) > > > > Is this a normal alert? Any idea? > > > > My CPU is an Intel Core i5 750 @ 2.67 Ghz, > > It is a "ASUS P7H55-M SI" computer. > > > > I've sent the following details to dm...@openbsd.org; > > > > dmesg, sysctl hw, sysctl hw.sensors outputs are here: > > > > http://pastebin.com/raw.php?i=BUm5ENvv > > > > Thanks. > > > > For speedstep you need something ___similar___ to this. > Didn't bother to look up the supported fsbfreqs, just remembered > something bout 133MHz base clock. (check intel site or code and adapt) > Atleast this should get you an idea where the love is needed. No, the ACPI PSS paths need to be rewritten to use different MSRs for newer intel processors otherwise bad things will happen.
Re: unknown i686 model 0x1e, can't get bus clock (0x0)
On Wed, 2 Jun 2010 13:54:34 +0300
"kryptos...@gmail.com " wrote:
> Hi,
>
> On OpenBSD 4.7, my dmesg output has the following alerts:
>
> cpu1: unknown i686 model 0x1e, can't get bus clock (0x0)
> cpu2: unknown i686 model 0x1e, can't get bus clock (0x0)
> cpu3: unknown i686 model 0x1e, can't get bus clock (0x0)
>
> Is this a normal alert? Any idea?
>
> My CPU is an Intel Core i5 750 @ 2.67 Ghz,
> It is a "ASUS P7H55-M SI" computer.
>
> I've sent the following details to dm...@openbsd.org;
>
> dmesg, sysctl hw, sysctl hw.sensors outputs are here:
>
> http://pastebin.com/raw.php?i=BUm5ENvv
>
> Thanks.
>
For speedstep you need something ___similar___ to this.
Didn't bother to look up the supported fsbfreqs, just remembered
something bout 133MHz base clock. (check intel site or code and adapt)
Atleast this should get you an idea where the love is needed.
Index: est.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/est.c,v
retrieving revision 1.19
diff -u -p -u -p -r1.19 est.c
--- est.c 20 Apr 2010 22:05:41 - 1.19
+++ est.c 2 Jun 2010 19:13:14 -
@@ -216,6 +216,19 @@ p3_get_bus_clock(struct cpu_info *ci)
break;
}
break;
+ case 0x1e: /* Intel Core i5 */
+ msr = rdmsr(MSR_FSB_FREQ);
+ bus = (msr >> 0) & 0x7;
+ switch (bus) {
+ case 1:
+ bus_clock = BUS133;
+ break;
+ default:
+ printf("%s: unknown Core i5 FSB_FREQ value %d",
+ ci->ci_dev->dv_xname, bus);
+ break;
+ }
+ break;
default:
printf("%s: unknown i686 model 0x%x, can't get bus clock\n",
ci->ci_dev->dv_xname, ci->ci_model);
Re: unknown i686 model 0x1e, can't get bus clock (0x0)
weird... Maybe OpenBSD doesn't support Intel Core i5 750? cool mainboard, btw.. On 2 June 2010 13:54, kryptos...@gmail.com wrote: > Hi, > > On OpenBSD 4.7, my dmesg output has the following alerts: > > cpu1: unknown i686 model 0x1e, can't get bus clock (0x0) > cpu2: unknown i686 model 0x1e, can't get bus clock (0x0) > cpu3: unknown i686 model 0x1e, can't get bus clock (0x0) > > Is this a normal alert? Any idea? > > My CPU is an Intel Core i5 750 @ 2.67 Ghz, > It is a "ASUS P7H55-M SI" computer. > > I've sent the following details to dm...@openbsd.org; > > dmesg, sysctl hw, sysctl hw.sensors outputs are here: > > http://pastebin.com/raw.php?i=BUm5ENvv > > Thanks.
Re: (unknown)
On 2009-05-27, Bob Beck Via Secure Email wrote: > Hi this is bob. really. > I can haz Ur Passwordz plz? > > ohai, and Ur bank accountz and sinz too? > > Ya. http://www.uknof.org.uk/uknof13/Fowler-Phish.pdf
Re: Unknown "." dir in a daily insecurity report
On Oct 26, 2006, at 4:04 AM, Otto Moerbeek wrote: On Thu, 26 Oct 2006, Patrick Rutkowski wrote: I don't know what I'm supposed to make of this: === Start Message === Subject: daily insecurity output Checking special files and directories. Output format is: filename: criteria (shouldbe, reallyis) .: permissions (0755, 0777) === End Message === Normally I don't get daily insecurity reports, which I take to mean that everything is OK. But for the past two nights I have gotten this one; and I can't figure out what it's trying to tell me. sudo find / -perm 777 will show no output other than when I deliberately create a single chmod 777 file, at which point it will show only that one file. This proves that that find is working properly and that there are, as far as I can tell, no chmod 777 files on my system. The only thing worth mentioning about my system is that it's still running 3.8. It looks like your / dir has the wrong permissions. -Otto Yup, that was it; ty :-D
Re: Unknown "." dir in a daily insecurity report
On 26/10/06, Patrick Rutkowski <[EMAIL PROTECTED]> wrote: I don't know what I'm supposed to make of this: === Start Message === Subject: daily insecurity output Checking special files and directories. Output format is: filename: criteria (shouldbe, reallyis) .: permissions (0755, 0777) === End Message === Normally I don't get daily insecurity reports, which I take to mean that everything is OK. But for the past two nights I have gotten this one; and I can't figure out what it's trying to tell me. sudo find / -perm 777 will show no output other than when I deliberately create a single chmod 777 file, at which point it will show only that one file. This proves that that find is working properly and that there are, as far as I can tell, no chmod 777 files on my system. The only thing worth mentioning about my system is that it's still running 3.8. sudo chmod 755 /.
Re: Unknown "." dir in a daily insecurity report
On Thu, 26 Oct 2006, Patrick Rutkowski wrote: > I don't know what I'm supposed to make of this: > > === Start Message === > > Subject: daily insecurity output > > Checking special files and directories. > Output format is: > filename: > criteria (shouldbe, reallyis) > .: permissions (0755, 0777) > > === End Message === > > Normally I don't get daily insecurity reports, which I take to mean that > everything is OK. But for the past two nights I have gotten this one; and I > can't figure out what it's trying to tell me. > > sudo find / -perm 777 will show no output other than when I > deliberately create a single chmod 777 file, at which point it will show only > that one file. This proves that that find is working properly and that there > are, as far as I can tell, no chmod 777 files on my system. > > The only thing worth mentioning about my system is that it's still running > 3.8. It looks like your / dir has the wrong permissions. -Otto
Re: unknown dhcp option value 0x51
Hans van Leeuwen wrote: Hi, Since I first put an OpenBSD 3.5-box on my ADSL-line i've been getting messages like this every 30 minutes: "Aug 22 16:40:41 fortress-maximus dhclient[20645]: unknown dhcp option value 0x51" Isn't it the fqdn code for dhcp ? If it is, then it means your dhcp client tries to make the dhcp server records its fqdn (fully qualified domain name). If it's not, then I don't know... :( Antoine
