Re: 0.0.0.0/32 in pf's tables
a very clever man once said that God does not play dice.. and he was wrong! so it is too presumptuous to believe that you know the ways of the God ;) seriously, if i can use 0.0.0.0/32 in rules, then why can't i use the same in tables? i don't think God cares why i do it > God abhors a naked singularity. > On Tue, 2022-11-08 at 22:47 +0300, 3 wrote: >> what religion forbids using 0.0.0.0/32 in tables? 0_0 but 0/0 can be >> used.. what's going on?! is the world going mad? >>
Re: 7.2 miniupnpd
> I don't use upnp, but surely you're going to have some problems > with this upstream NAT... or maybe i'm crazy..? 0_o what business can a program have to what happens outside of its narrow little world consisting of two local interfaces? it's none of her business what happens on the other router. her job is to open ports on the local router on command. she cannot know at all where her place in this world is. hell, even i don't know that! %D but the author of miniupnpd believes that he knows better than me where i am and how to live in this place, what i can do and what i can't do. this is some kind of madness.. that's just not clear whose %\
0.0.0.0/32 in pf's tables
what religion forbids using 0.0.0.0/32 in tables? 0_0 but 0/0 can be used.. what's going on?! is the world going mad?
Re: 7.2 miniupnpd
sorry, guys. it turned out that this is not a bug, but just the author of the program has gone mad. he considers himself the ruler of the galaxy and points out how we should live :D although it's not funny at all :\ > hi, men. > it doesn't work only for me? as long as i can remember, there have always > been problems with him. who can tell anything about how to fix? or may be any > alternative of miniupnpd that works. > i tried different build options, but didn't find a working combination. no > rules are created in the anchor.
7.2 miniupnpd
hi, men. it doesn't work only for me? as long as i can remember, there have always been problems with him. who can tell anything about how to fix? or may be any alternative of miniupnpd that works. i tried different build options, but didn't find a working combination. no rules are created in the anchor. --- ext_ifname=pppoe0 ext_perform_stun=yes ext_stun_host=stun.sipgate.net listening_ip=vport0 enable_natpmp=yes enable_upnp=yes secure_mode=no system_uptime=yes notify_interval=60 clean_ruleset_interval=600 anchor=miniupnpd uuid=---- allow 1024-65535 192.168.85.0/0 1024-65535 --- miniupnpd[31745]: version 2.3.0 starting NAT-PMP/PCP UPnP-IGD ext if pppoe0 BOOTID=1667848346 miniupnpd[31745]: STUN: Performing with host=stun.sipgate.net and port=0 ... miniupnpd[31745]: resolve_stun_host: stun.sipgate.net:3478 => 217.10.68.145:3478 miniupnpd[31745]: perform_stun: local ports 3751 46253 4061 16242 miniupnpd[31745]: wait_for_stun_responses: waiting 3 secs and 0 usecs miniupnpd[31745]: wait_for_stun_responses: received responses: 1 miniupnpd[31745]: wait_for_stun_responses: waiting 3 secs and 0 usecs miniupnpd[31745]: wait_for_stun_responses: select(): no more responses miniupnpd[31745]: wait_for_stun_responses: waiting 3 secs and 0 usecs miniupnpd[31745]: wait_for_stun_responses: select(): no more responses miniupnpd[31745]: wait_for_stun_responses: waiting 3 secs and 0 usecs miniupnpd[31745]: wait_for_stun_responses: select(): no more responses miniupnpd[31745]: parse_stun_response: Type 0x0101, Length 68, Magic Cookie 2112a442 miniupnpd[31745]: parse_stun_response: MAPPED-ADDRESS 109.106.141.221:64758 miniupnpd[31745]: parse_stun_response: SOURCE-ADDRESS 217.10.68.145:3478 miniupnpd[31745]: parse_stun_response: CHANGED-ADDRESS 217.116.122.143:3479 miniupnpd[31745]: parse_stun_response: XOR-MAPPED-ADDRESS 109.106.141.221:64758 miniupnpd[31745]: parse_stun_response: SOFTWARE Vovida.org 0.96 miniupnpd[31745]: perform_stun: 1 response out of 4 received miniupnpd[31745]: perform_stun: #0 external address or port changed miniupnpd[31745]: STUN: ext interface pppoe0 with private IP address 172.25.231.96 is now behind restrictive or symmetric NAT with public IP address 109.106.141.221 which does not support port forwarding miniupnpd[31745]: NAT on upstream router blocks incoming connections set by miniupnpd miniupnpd[31745]: Turn off NAT on upstream router or change it to full-cone NAT 1:1 type miniupnpd[31745]: Port forwarding is now disabled miniupnpd[31745]: HTTP listening on port 29442 miniupnpd[31745]: Listening for NAT-PMP/PCP traffic on port 5351 miniupnpd[31745]: HTTP REQUEST from 192.168.85.23:57638 : GET /rootDesc.xml (HTTP/1.1) miniupnpd[31745]: Host: 192.168.85.1:29442 miniupnpd[31745]: 200 rt_msg : msglen=200 version=5 type=14 miniupnpd[31745]: RTM_IFINFO: addrs=10 flags=8b43 index=4 miniupnpd[31745]: 200 rt_msg : msglen=200 version=5 type=14 miniupnpd[31745]: RTM_IFINFO: addrs=10 flags=8b43 index=4 miniupnpd[31745]: level=0 type=30 miniupnpd[31745]: sdl_index = 10 vport0:0.0.0.0.0.1 miniupnpd[31745]: ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1 (ver=1) miniupnpd[31745]: SSDP M-SEARCH from 192.168.85.23:58827 ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1 miniupnpd[31745]: Single search found miniupnpd[31745]: SendSSDPResponse(): 0 bytes to 192.168.85.23:58827 ST: HTTP/1.1 200 OK CACHE-CONTROL: max-age=120 ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1 USN: uuid:----::urn:schemas-upnp-org:device:InternetGatewayDevice:1 EXT: SERVER: OpenBSD/7.2 UPnP/1.1 MiniUPnPd/2.3.0 LOCATION: http://192.168.85.1:29442/rootDesc.xml OPT: "http://schemas.upnp.org/upnp/1/0/;; ns=01 01-NLS: 1667848346 BOOTID.UPNP.ORG: 1667848346 CONFIGID.UPNP.ORG: 1337 miniupnpd[31745]: HTTP REQUEST from 192.168.85.23:57640 : GET /rootDesc.xml (HTTP/1.1) miniupnpd[31745]: Host: 192.168.85.1:29442 miniupnpd[31745]: HTTP REQUEST from 192.168.85.23:57641 : POST /ctl/IPConn (HTTP/1.1) miniupnpd[31745]: Host: 192.168.85.1:29442 miniupnpd[31745]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetStatusInfo miniupnpd[31745]: HTTP REQUEST from 192.168.85.23:57642 : POST /ctl/IPConn (HTTP/1.1) miniupnpd[31745]: Host: 192.168.85.1:29442 miniupnpd[31745]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetExternalIPAddress miniupnpd[31745]: HTTP REQUEST from 192.168.85.23:57643 : POST /ctl/IPConn (HTTP/1.1) miniupnpd[31745]: Host: 192.168.85.1:29442 miniupnpd[31745]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetExternalIPAddress miniupnpd[31745]: HTTP REQUEST from 192.168.85.23:57644 : POST /ctl/IPConn (HTTP/1.1) miniupnpd[31745]: Host: 192.168.85.1:29442 miniupnpd[31745]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping miniupnpd[31745]: AddPortMapping: ext p
Re: console in mc like in linux
> ... I added support for OpenBSD's ksh to the port in -current i have heard different versions about the reasons for this, but there was no version about dependence on shell. really works with bash! but thank you for the opportunity not to use bash ;)
console in mc like in linux
sorry guys for the stupid question, but the answers to stupid questions keep the world going :) in linux, there is a convenient feature in mc, when when pressing ctrl-o we not only see the console, but also we can execute commands in it. how to achieve this in obsd? it's about remote access via putty, if it matters(i have no way to test the behavior without putty)
there is a dhcp ipv6 server that can dynamically configurated?
the rad+slaacd scheme is described everywhere, but if Windows is used instead of slaacd then when you change the prefix, Windows gets the address from the new prefix, but does not remove the old one. as a result ipv6 routing does not work. so i want to make a stateful configuration in which(i hope) Windows will take new address and remove old addresses. but i can not find the dhcp server in the config where i can set a prefix as a "variable". maybe there are other ways that are not obvious for me?
Re: bwfm bcm43569
> Babut, > You are not correct, OpenBSD is a full Unix/BSD implementation and can > do most anything BSD/Unix can. > I guess in the whole domain of general purpose functionality, > concurrent disk/filesystem IO performance would be OpenBSD's humblest > point today (due to not using block device multiqueueing and I get the > impression that the disk/IO subsystem is mostly not parallellized, for > some usecases also the 3GB buffer cap limit matters). > Joseph obsd do not have a reliable file system and nothing is being done in this direction. the fact that disk operations are slow is not so important for me(with the advent of ssd, this problem has ceased to be relevant). the hardware support is in a terrible state and relative situation is getting worse(i am not even talking about the drivers but about all the 802.11 subsystem which still does not know how to 11ac, although during this time it is outdated. and i suspect theo will cut out the 802.11 subsystem soon because no 802.11- no problem. it is obsd style). obsd has never been strong on multitasking, but now they are trying to make it worse(thank god that ht support still kept). these disadvantages narrow the area where you can use obsd. your very approach to evaluate the completeness of compliance with some concept(as unix) is flawed. people do not use concepts in everyday life, they use some opportunities. and it is necessary to adjust the concept to what is demanded by people and not to limit opportunities because of the concept. and although theo is wrong, obsd is his brainchild and he has the right to kill him :\ ps: any fictional concepts is bullshit. there are only practical needs and common sense
Re: bwfm bcm43569
> On Tue, Jun 25, 2019 at 12:06:51AM +0300, 3 wrote: >> i know that wifi adapters never worked in obsd(excluding those >> adapters for which drivers were written by vendors), but i found one >> that shows signs of life in 11n(11ac 2t2r supported by chip). it can >> be bought anywhere where there are samsung tv. moreover it even works >> in hostap mode(unlike the buggy athn). >> but without a ton of bugs not done: >> bwfm0: could not read register: TIMEOUT >> bwfm0: could not open rx pipe: IN_USE >> bwfm0: could not init bus >> bwfm0: firmware did not start up >> .and sometimes kernel panic on boot, but works would still! >> meet https://wikidevi.com/wiki/Samsung_WCH730B >> bwfm0 at uhub0 port 1 configuration 1 interface 0 "Broadcom BCMUSB 802.11 >> Wireless Adapter" rev 2.10/0.01 addr 2 >> photo without cover: http://pichost.org/images/2019/06/24/Untitled-138.jpg >> it is shown where to solder the wires for wifi. on the right through >> two pins(ground is first) is bluetooth, but for obsd this does not >> matter(thx theo). >> data sheet for chip: https://www.cypress.com/file/310246/download > Did you solder that yourself? As long as nothing has changed, bwfm(4) > on USB worked fine with the one USB one that I had: The official > raspberry Pi USB WiFi stick that they sold before they put the WiFi > chip onto the board itself. I wouldn't blame that on the driver. > Did you try the stick with Linux? If it works with Linux then maybe > it's my fault after all. > Patrick not me but i asked another man to find for me where the usb pins out. i can not overpower myself and use monkey style os like a linux :\ so i have not tested on linux. but if you care i will give you any information you need
Re: bwfm bcm43569
> Provide a dmesg before you rant. > Thanks, > Brian >> On Jun 24, 2019, at 5:06 PM, 3 wrote: >> >> i know that wifi adapters never worked in obsd(excluding those >> adapters for which drivers were written by vendors), but i found one >> that shows signs of life in 11n(11ac 2t2r supported by chip). it can >> be bought anywhere where there are samsung tv. moreover it even works >> in hostap mode(unlike the buggy athn). >> but without a ton of bugs not done: >> bwfm0: could not read register: TIMEOUT >> bwfm0: could not open rx pipe: IN_USE >> bwfm0: could not init bus >> bwfm0: firmware did not start up >> ..and sometimes kernel panic on boot, but works would still! >> meet https://wikidevi.com/wiki/Samsung_WCH730B >> bwfm0 at uhub0 port 1 configuration 1 interface 0 "Broadcom BCMUSB 802.11 >> Wireless Adapter" rev 2.10/0.01 addr 2 >> photo without cover: http://pichost.org/images/2019/06/24/Untitled-138.jpg >> it is shown where to solder the wires for wifi. on the right through >> two pins(ground is first) is bluetooth, but for obsd this does not >> matter(thx theo). >> data sheet for chip: https://www.cypress.com/file/310246/download >> for what? but as you wish. if you want to see driver's error messages or kernel panic just say it because they do not always appear. but we both know it is a waste of time and it will not lead to anything. OpenBSD 6.5 (BABUT) #6: Sun May 19 18:12:47 MSK 2019 r...@gw.pesec.cf:/usr/src/sys/arch/amd64/compile/BABUT real mem = 8481652736 (8088MB) avail mem = 8214913024 (7834MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xabaac000 (49 entries) bios0: vendor American Megatrends Inc. version "5.11" date 04/13/2018 acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI LPIT CSRT acpi0: wakeup devices SIO1(S0) BRC1(S0) XHC1(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU J3160 @ 1.60GHz, 1600.32 MHz, 06-4c-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN cpu0: 1MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 80MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) CPU J3160 @ 1.60GHz, 1600.00 MHz, 06-4c-04 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Celeron(R) CPU J3160 @ 1.60GHz, 1600.01 MHz, 06-4c-04 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN cpu2: 1MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Celeron(R) CPU J3160 @ 1.60GHz, 1600.03 MHz, 06-4c-04 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN cpu3: 1MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 3 (RP03) acpiprt4 at acpi0: bus 4 (RP04) acpiec0 at acpi0: not present acpicpu0 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(10@1000 mwait.1
Re: bwfm bcm43569
> 2019-06-24 23:06 GMT+02:00, 3 : >> i know that wifi adapters never worked in obsd(excluding those > I doubt that they never worked. Check this out: > https://man.openbsd.org/usb#Wireless_network_interfaces > You can find specific devices under each driver. For example I use an > Asus USB-N10 nano which works with the urtwn(4) driver >> adapters for which drivers were written by vendors), but i found one >> that shows signs of life in 11n(11ac 2t2r supported by chip). it can >> be bought anywhere where there are samsung tv. moreover it even works >> in hostap mode(unlike the buggy athn). >> but without a ton of bugs not done: >> bwfm0: could not read register: TIMEOUT >> bwfm0: could not open rx pipe: IN_USE >> bwfm0: could not init bus >> bwfm0: firmware did not start up >> ..and sometimes kernel panic on boot, but works would still! >> meet https://wikidevi.com/wiki/Samsung_WCH730B >> bwfm0 at uhub0 port 1 configuration 1 interface 0 "Broadcom BCMUSB 802.11 >> Wireless Adapter" rev 2.10/0.01 addr 2 >> photo without cover: http://pichost.org/images/2019/06/24/Untitled-138.jpg >> it is shown where to solder the wires for wifi. on the right through >> two pins(ground is first) is bluetooth, but for obsd this does not >> matter(thx theo). >> data sheet for chip: https://www.cypress.com/file/310246/download >> >> first, urtwn doesn't support 11n. i have not checked but it is written there. second, hostap mode is not supported. third, the only one task that obsd can solve is to be a router. nothing more but even this task obsd can not solve adequately. and for this you need wifi support with hostap mode. if you have a device from the china there is usually a mini-pcie only with usb interface. for example https://aliexpress.com/item/Minisys-NUC-Celeron-J3160-4-4-Intel-i210AT-Nic-X86/32891699351.html only two drivers fit- athn and bwfm, but i could not get athn to work witn TL-WN821N(r3,r5)
bwfm bcm43569
i know that wifi adapters never worked in obsd(excluding those adapters for which drivers were written by vendors), but i found one that shows signs of life in 11n(11ac 2t2r supported by chip). it can be bought anywhere where there are samsung tv. moreover it even works in hostap mode(unlike the buggy athn). but without a ton of bugs not done: bwfm0: could not read register: TIMEOUT bwfm0: could not open rx pipe: IN_USE bwfm0: could not init bus bwfm0: firmware did not start up ..and sometimes kernel panic on boot, but works would still! meet https://wikidevi.com/wiki/Samsung_WCH730B bwfm0 at uhub0 port 1 configuration 1 interface 0 "Broadcom BCMUSB 802.11 Wireless Adapter" rev 2.10/0.01 addr 2 photo without cover: http://pichost.org/images/2019/06/24/Untitled-138.jpg it is shown where to solder the wires for wifi. on the right through two pins(ground is first) is bluetooth, but for obsd this does not matter(thx theo). data sheet for chip: https://www.cypress.com/file/310246/download
Re: athn0: bad ROM checksum 0x2c64
> On Sun, May 19, 2019 at 12:33:33PM +0300, 3 wrote: >> shit. i have upgraded to 6.5 and now the interface is losing settings >> after about 30 seconds: >> athn0: flags=8843 mtu 1500 >> lladdr b0:48:7a:8c:41:79 >> index 17 priority 4 llprio 3 >> groups: wlan >> media: IEEE802.11 autoselect (DS1) >> status: no network >> ieee80211: nwid "" >> >> but within 30 seconds it works(though losing a lot of packets). >> maybe some more rescue patches? ;) >> >> ps: >> athn0 at uhub0 port 5 configuration 1 interface 0 "ATHEROS USB WLAN" rev >> 2.00/2.02 addr 3 >> athn0: AR9287 rev 2 (2T2R), ROM rev 4, address b0:48:7a:8c:41:79 >> > Try -current. kevlo@ has comitted a fix for this device. i built the kernel with its fixes. little has changed. now after rebooting the device does not up(netstart does not help), only a physical power outage helps. but after that only sometimes the device works as it should, more often it turns off after about 30 seconds. in this case, netstart helps to start the device again, more often for 30 seconds, but sometimes it continues to work as it should. all this is very sad -_-
Re: athn0: bad ROM checksum 0x2c64
> This should fix attach but there's some other remaining problem.
> The device detaches itself again when I try to use it.
> diff 709e530bc956c51de2da4aff727d8da450babdc4 /usr/src
> blob - 74025dba1aff37e328c92779398e428caef72c04
> file + sys/dev/ic/ar9287.c
> --- sys/dev/ic/ar9287.c
> +++ sys/dev/ic/ar9287.c
> @@ -100,7 +100,8 @@ voidar9280_spur_mitigate(struct athn_softc *,
> struct
> int
> ar9287_attach(struct athn_softc *sc)
> {
- sc->>eep_base = AR9287_EEP_START_LOC;
+ sc->>eep_base = (sc->flags & ATHN_FLAG_USB) ?
> + AR9287_HTC_EEP_START_LOC : AR9287_EEP_START_LOC;
> sc->eep_size = sizeof(struct ar9287_eeprom);
> sc->ngpiopins = (sc->flags & ATHN_FLAG_USB) ? 16 : 11;
> sc->led_pin = 8;
> blob - 340b28c2f84de4d40f15c42f13b1727a6f497bb0
> file + sys/dev/ic/ar9287reg.h
> --- sys/dev/ic/ar9287reg.h
> +++ sys/dev/ic/ar9287reg.h
> @@ -60,6 +60,7 @@
> * ROM layout used by AR9287 (2GHz only).
> */
> #define AR9287_EEP_START_LOC 128
> +#define AR9287_HTC_EEP_START_LOC 256
> #define AR9287_NUM_2G_CAL_PIERS 3
> #define AR9287_NUM_2G_CCK_TARGET_POWERS3
> #define AR9287_NUM_2G_20_TARGET_POWERS 3
shit. i have upgraded to 6.5 and now the interface is losing settings
after about 30 seconds:
athn0: flags=8843 mtu 1500
lladdr b0:48:7a:8c:41:79
index 17 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect (DS1)
status: no network
ieee80211: nwid ""
but within 30 seconds it works(though losing a lot of packets).
maybe some more rescue patches? ;)
ps:
athn0 at uhub0 port 5 configuration 1 interface 0 "ATHEROS USB WLAN" rev
2.00/2.02 addr 3
athn0: AR9287 rev 2 (2T2R), ROM rev 4, address b0:48:7a:8c:41:79
Re: athn0: bad ROM checksum 0x2c64
> This should fix attach but there's some other remaining problem.
> The device detaches itself again when I try to use it.
> diff 709e530bc956c51de2da4aff727d8da450babdc4 /usr/src
> blob - 74025dba1aff37e328c92779398e428caef72c04
> file + sys/dev/ic/ar9287.c
> --- sys/dev/ic/ar9287.c
> +++ sys/dev/ic/ar9287.c
> @@ -100,7 +100,8 @@ voidar9280_spur_mitigate(struct athn_softc *,
> struct
> int
> ar9287_attach(struct athn_softc *sc)
> {
- sc->>eep_base = AR9287_EEP_START_LOC;
+ sc->>eep_base = (sc->flags & ATHN_FLAG_USB) ?
> + AR9287_HTC_EEP_START_LOC : AR9287_EEP_START_LOC;
> sc->eep_size = sizeof(struct ar9287_eeprom);
> sc->ngpiopins = (sc->flags & ATHN_FLAG_USB) ? 16 : 11;
> sc->led_pin = 8;
> blob - 340b28c2f84de4d40f15c42f13b1727a6f497bb0
> file + sys/dev/ic/ar9287reg.h
> --- sys/dev/ic/ar9287reg.h
> +++ sys/dev/ic/ar9287reg.h
> @@ -60,6 +60,7 @@
> * ROM layout used by AR9287 (2GHz only).
> */
> #define AR9287_EEP_START_LOC 128
> +#define AR9287_HTC_EEP_START_LOC 256
> #define AR9287_NUM_2G_CAL_PIERS 3
> #define AR9287_NUM_2G_CCK_TARGET_POWERS3
> #define AR9287_NUM_2G_20_TARGET_POWERS 3
thx! your hack does work with "rev 2.00/2.02" on 6.4. tested with
firmware from 6.3, 6.4, 6.5, current. binary 1.1p4 differ from other
1.1p4 %\ tested only AP mode
Re: counting dropped packets for pf
> On Fri, Mar 30, 2018 at 9:58 AM, 3 <ba...@yandex.ru> wrote: >> perhaps my poor english prevented you from understanding the question > perhaps >> my initial approach does work. u are have comments about route-to? > If people do not understand the words you use to represent the ideas > you were thinking, does that matter? i showed my idea on the example of pf's config- this language should be familiar to you > If there are more efficient ways of accomplishing the same thing, is > it important? no more effective ways. the variant with pfctl is a kolhoz-style(ugly and ineffective), it requires a lot of work to convert data into netflow format > [regardless, I am going back to lurking and trying to figure out a > good way to install current on a system I use.] > Thanks,
Re: counting dropped packets for pf
> On 03/30/18 13:32, 3 wrote: >> people like you do not understand what better badly does work than >> well not works. and it is not our(not ordinary users) fault that the > Seriously, cipher, you're just spewing word salad again. > And it sounds vaguely like abuse, aimed at people who were in fact > offering useful suggestions. to give useful suggestions first need to understand the question. perhaps my poor english prevented you from understanding the question > Some of us were able to decipher what we thought was your problem > (wanting to record dropped packets) and offered suggestions on how to do > that along with the explanation why your original approach was never > going to work. my initial approach does work. u are have comments about route-to? > If you really want to record your dropped packets in a netflow format, > there's nothing stopping you from implementing just that. in next time remind yourself that you can surgery on your own, instead of going to a surgeon > Whether your implementation will be accepted back the OpenBSD source > tree is of course a different and separate question. i am a ordinary user(not a surgeon) and have already talked about it, but my poor english.. > One thing is certain, though: Spewing abuse-ish word salad at mailing > lists is not going to get you anywhere. sorry about that -_- i should have left as soon as i understand we were living in different worlds
Re: counting dropped packets for pf
>> You would need a 1/4" wrench and a screwdriver tip that fits an impact >> driver. > I want to see you using your method for a deep sunken screw inside a > cylindrical channel of a case. > You can give a chance to the other guy, too. > People like you do not understand concepts like evolution, smart > tools, unix simplicity, KISS, etc. people like you do not understand what better badly does work than well not works. and it is not our(not ordinary users) fault that the progress of obsd is only to cut poorly functioning parts without giving anything instead. teo and your ideal fucking unix system is "hello, world!" with two remote holes in the default install. but you are too d^Hstubborn to understand that such a system is not necessary for ordinary users. i like pf and i hate dirty monkey's style of linux, but there will come a time when this will not be enough to choose obsd
Re: counting dropped packets for pf
> man pf.conf is your friend, please consult there before letting > resentment stew for years next time, huh? why are you silent? do you have the courage to admit that the famous russian comedian zadornov was right when said "ну тупые!"? ;)
Re: counting dropped packets for pf
> On 03/28/18 22:03, 3 wrote: >> maybe im so dumb and blind to see pflow here.. and maybe deal not in >> me. where is pflow? > pflow gets the data it exports from the state table. > Blocked connections do not create state table entries. > This means that pflow does not have the information you're looking for. > You can still get detailed information about blocked connection > attempts, in the aggregate via labels as I showed you, or from pflog. > You could even have your block rules logged to a separate pflog interface. > Others have alredy pointed you at other alternatives. Obsessing about > pflow unfortunately isn't going to get you anywhere. Exploring the other > options might. i accept your challenge! ^^ but first i will describe my scheme of pf.conf(this is important): block all # default block match from (self) tag PASS # default output match bla-bla1 to (self) tag PASS match bla-bla2 to (self) tag PASS .. match bla-blaN to (self) tag PASS match from lan:network tag PASS # its actually an anchor here, loadable from match to lan:network tag PASS # another file, but it does not matter match out on egress inet from !(self) tagged PASS nat-to (egress) # nat pass quick tagged PASS # one(no other) final pass -- in this place we have all the packets that were not accepted and that will be later blocked by the default block. -- we need only those who entered on egress(pppoe0 for me): pass in quick on pppoe0 all route-to(vether0 10.0.0.1) keep state (pflow) # any fake inteface is here -- now all these packets selected by us get back to the entrance of the rules(before default block). -- we can leave them as they are, but its better to delete them: block quick on vether0 # need to place as the first rule -- lets see what we have got if enable logging: Mar 29 20:42:46.984161 rule 92/(match) [uid 0, pid 54243] pass in on pppoe0: 24.201.182.114.46574 > 188.235.31.7.36824: [udp sum ok] udp 20 [tos 0x70] (ttl 53, id 5542, len 48) Mar 29 20:42:46.984176 rule 0/(match) [uid 0, pid 54243] block out on vether0: 24.201.182.114.46574 > 188.235.31.7.36824: [udp sum ok] udp 20 [tos 0x70] (ttl 53, id 5542, len 48) .. and more(i found four matching packets in this interval, but it is difficult to synchronize pf's log and log of the flowd) process_flow: ACCEPT flow FLOW recv_time 2018-03-29T20:43:42.634715 proto 17 tcpflags 00 tos 00 agent [127.0.0.1] src [24.201.182.114]:46574 dst [188.235.31.7]:36824 gateway [0.0.0.0] packets 3 octets 144 in_if 7 out_if 0 sys_uptime_ms 2h20m51s.000 time_sec 2018-03-29T20:43:42 time_nanosec 634520582 netflow ver 5 flow_start 2h19m55s.000 flow_finish 2h20m5s.000 src_AS 0 src_masklen 0 dst_AS 0 dst_masklen 0 engine_type 10752 engine_id 10752 seq 11273 source 0 crc32 output_flow_enqueue: offset 1624 alloc 16384 -- what you say? ;)
Re: counting dropped packets for pf
Вы писали 29 марта 2018 г., 16:35:45: > On Wed, Mar 28, 2018, at 7:10 PM, 3 wrote: >> > 3(ba...@yandex.ru) on 2018.03.28 23:03:27 +0300: >> >> > On 03/28/18 15:04, 3 wrote: >> >> >> hi guys. when the pflow option first appeared, i was surprised by the >> >> >> stupidity of those who implemented it- pflow could not be specified >> >> >> for block-rules, i.e. dropped packets were not taken into account. as >> i understand- no kosher ways. im asking for illegal ways. many years >> ago there was no way either, but i found a way out. i dont think you >> are dumber than me >> > You are asking, "How do I use a wrench as a screwdriver?" yep. and comrade ed...@pettijohn-web.com understand me. hello, edgar. you are smart ^_^
Re: counting dropped packets for pf
> 3(ba...@yandex.ru) on 2018.03.28 23:03:27 +0300: >> > On 03/28/18 15:04, 3 wrote: >> >> hi guys. when the pflow option first appeared, i was surprised by the >> >> stupidity of those who implemented it- pflow could not be specified >> >> for block-rules, i.e. dropped packets were not taken into account. as >> >> > hm. you've suffered nine years of this stupidity of others but have not >> > been able to add labels to your block rules? >> >> > Just as an experiment I added labels to the block rules on my >> > most-easily-reachable-from-here gateway, as in >> >> > block log (all) label blockgen >> > block drop log (all) quick from label portalbrutes >> > block drop log (all) quick from label abusives >> > block drop log (all) quick from label webtrash >> > block drop log (all) quick from label bruteforce >> >> > block drop log (all) quick from label longterm >> > block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11 >> >> > and voila, pfctl -sl gives me after a few minutes >> >> > [Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl >> > blockgen 3739 452 19856 448 19664 4 192 0 >> > portalbrutes 3739 0 0 0 0 0 0 0 >> > abusives 3739 301 14681 301 14681 0 0 0 >> > webtrash 3438 0 0 0 0 0 0 0 >> > bruteforce 3438 0 0 0 0 0 0 0 >> > longterm 3438 0 0 0 0 0 0 0 >> > remotex11 3438 0 0 0 0 0 0 0 >> >> > man pf.conf is your friend, please consult there before letting >> > resentment stew for years next time, huh? >> >> maybe im so dumb and blind to see pflow here.. and maybe deal not in >> me. where is pflow? > pflow can't export data for blocked packets. > It also does not send statistics. i understand- no kosher ways. im asking for illegal ways. many years ago there was no way either, but i found a way out. i dont think you are dumber than me
Re: counting dropped packets for pf
> https://man.openbsd.org/pflow.4 > On Wed, Mar 28, 2018 at 4:03 PM, 3 <ba...@yandex.ru> wrote: >> On 03/28/18 15:04, 3 wrote: >>> hi guys. when the pflow option first appeared, i was surprised by the >>> stupidity of those who implemented it- pflow could not be specified >>> for block-rules, i.e. dropped packets were not taken into account. as >> hm. you've suffered nine years of this stupidity of others but have not >> been able to add labels to your block rules? >> Just as an experiment I added labels to the block rules on my >> most-easily-reachable-from-here gateway, as in >> block log (all) label blockgen >> block drop log (all) quick from label portalbrutes >> block drop log (all) quick from label abusives >> block drop log (all) quick from label webtrash >> block drop log (all) quick from label bruteforce >> block drop log (all) quick from label longterm >> block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11 >> and voila, pfctl -sl gives me after a few minutes >> [Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl >> blockgen 3739 452 19856 448 19664 4 192 0 >> portalbrutes 3739 0 0 0 0 0 0 0 >> abusives 3739 301 14681 301 14681 0 0 0 >> webtrash 3438 0 0 0 0 0 0 0 >> bruteforce 3438 0 0 0 0 0 0 0 >> longterm 3438 0 0 0 0 0 0 0 >> remotex11 3438 0 0 0 0 0 0 0 >> man pf.conf is your friend, please consult there before letting >> resentment stew for years next time, huh? > maybe im so dumb and blind to see pflow here.. and maybe deal not in > me. where is pflow? continue your thought. we have the output of the pfctl -vsl command, which in this form is useless, since the output is needed in the netflow format. there is a man pflow - one piece(its not clear why we need it if we abandoned the pflow and went to the output of pfctl -vsl). how do cooking a netflow stream from this?
Re: counting dropped packets for pf
> On 03/28/18 15:04, 3 wrote: >> hi guys. when the pflow option first appeared, i was surprised by the >> stupidity of those who implemented it- pflow could not be specified >> for block-rules, i.e. dropped packets were not taken into account. as > hm. you've suffered nine years of this stupidity of others but have not > been able to add labels to your block rules? > Just as an experiment I added labels to the block rules on my > most-easily-reachable-from-here gateway, as in > block log (all) label blockgen > block drop log (all) quick from label portalbrutes > block drop log (all) quick from label abusives > block drop log (all) quick from label webtrash > block drop log (all) quick from label bruteforce > block drop log (all) quick from label longterm > block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11 > and voila, pfctl -sl gives me after a few minutes > [Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl > blockgen 3739 452 19856 448 19664 4 192 0 > portalbrutes 3739 0 0 0 0 0 0 0 > abusives 3739 301 14681 301 14681 0 0 0 > webtrash 3438 0 0 0 0 0 0 0 > bruteforce 3438 0 0 0 0 0 0 0 > longterm 3438 0 0 0 0 0 0 0 > remotex11 3438 0 0 0 0 0 0 0 > man pf.conf is your friend, please consult there before letting > resentment stew for years next time, huh? maybe im so dumb and blind to see pflow here.. and maybe deal not in me. where is pflow?
counting dropped packets for pf
hi guys. when the pflow option first appeared, i was surprised by the stupidity of those who implemented it- pflow could not be specified for block-rules, i.e. dropped packets were not taken into account. as a result of this approach, the usefulness of pflow sought to zero for those cases where traffic really had to be counted. but then i found the way out- the default blocking rule first duplicated packets on a special, only for this created localhost, which had only one rule - receiving all incoming packets and the pflow option set, this allowed to take into account dropped packets too. now i updated system, and saw that the low level taken by developers fell even lower- now it is impossible to specify dub-to for block-rules. i dont know how to get around this now, im a simple user and tired of fighting hands-from-ass developers. can anyone share their hacks for this? ps: sry for my english
RE:TE:360-0416/360-3673-SOL-PISCINAS-RESTAURANTS-BUMGALOWS-SALONES DE CONFERENCIAS-ESPARCIMIENTO-PVBLIC_I_dad
http://www.cristoysusamigos.com/laderas.jpg VIERNES,SABADO,DOMINGO VENGAN A PASAR EL DIA CON NOSOTROS HAGA SU RESERVA. (Dias de semana, previa llamada telefonica) 360-0416 /360-3673 /360-2189 * VEINTE MIL M2 DE AREAS VERDES * ALQUILER DE BUNGALOWS * RESTAURANT,BAR,POLLOS A LA LEÑA,ALQUILER DE PARRILLAS * PISCINAS,PISCINA PARA NIÑOS,CANCHA DE FULBITO,PALETA FRONTON,VOLEY * PING PONG,BILLAR,FULBITO DE MANO,JUEGOS DE MESA * SUBIBAJA,CAMA ELASTICA,COLUMPIOS,PASAMANOS * EXCELENTE MICROCLIMA Y SOL TODO EL AÑO · DISPONEMOS DE EQUIPO DE KARAOKE * AREA DE CAMPING,CONSULTENOS INVITA A TU FAMILIA Y/O AMIGOS. ATENDEMOS COLEGIOS,RETIROS,CUMPLEAÑOS,FIESTAS INFANTILES, ALMUERZOS DE CAMARADERÍA,CONVENCIONES O EMPRESAS LOS ESTAREMOS ESPERANDO GUSTOSOS DE PODER ATENDERLOS. DIRECCION:AV EL BOSQUE 401 URBANIZACION CALIFORNIA ALTA,PASANDO CHACLACAYO ANTES DEL PUENTE LOS ANGELES NO LO CRUCE, SIGA DE FRENTE,PARALELO AL RIO. SIGA 2KM (TENEMOS SEÑALIZACION CARTELES FLECHAS DESDE 3.3KM ANTES. TELEFONOS:3603673,3600416 SI USTED TIENE INTERES EN QUE LE ENVIEMOS VISTAS DE NUESTRO LOCAL ENVIENOS UN E-MAILS SOLICITANDO FOTOS E-MAIL: las.lade...@nixmail.com Si solo desea pasar el día, hay un consumo mínimo de S/. 30.00 por persona adulta. El alquiler de parrilla: US. $ 10.00 ( Carbon, utensilios y todo tipo de salsas ) Aceptamos Tarjetas de Crédito ( Master Card, Visa, Diners Club.American Express y Ripley ). Para mayor información y reservaciones sírvase llamar a nuestros teléfonos 3603673 - 3600416 Atentamaente jonattan otero LIMA-PERU LAS LADERAS DE CALIFORNIA AGRADECE LA RECEPCION DE NUESTRO E-MAIL. Para no volver a recibir estos mensajes responda por favor escribiendo a: laderasremo...@mixmail.com REMOVER Y SERA REMOVIDO A LA BREVEDAD MUCHAS GRACIAS
Re: OFERTAS-SOL-PISCINAS-RESTAIURANTS-BUNGALOWS-ESPARCIMIENRTO_PUBL_I_CIDAD
[IMAGE] VIERNES,SABADO,DOMINGO VENGAN A PASAR EL DIA CON NOSOTROS HAGA SU RESERVA. (Dias de semana, previa llamada telefonica) 360-0416 /360-3673 /360-2189 * VEINTE MIL M2 DE AREAS VERDES * ALQUILER DE BUNGALOWS * RESTAURANT,BAR,POLLOS A LA LEQA,ALQUILER DE PARRILLAS * PISCINAS,PISCINA PARA NIQOS,CANCHA DE FULBITO,PALETA FRONTON,VOLEY * PING PONG,BILLAR,FULBITO DE MANO,JUEGOS DE MESA * SUBIBAJA,CAMA ELASTICA,COLUMPIOS,PASAMANOS * EXCELENTE MICROCLIMA Y SOL TODO EL AQO 7 DISPONEMOS DE EQUIPO DE KARAOKE * AREA DE CAMPING,CONSULTENOS INVITA A TU FAMILIA Y/O AMIGOS. ATENDEMOS COLEGIOS,RETIROS,CUMPLEAQOS,FIESTAS INFANTILES, ALMUERZOS DE CAMARADERMA,CONVENCIONES O EMPRESAS LOS ESTAREMOS ESPERANDO GUSTOSOS DE PODER ATENDERLOS. DIRECCION:AV EL BOSQUE 401 URBANIZACION CALIFORNIA ALTA,PASANDO CHACLACAYO ANTES DEL PUENTE LOS ANGELES NO LO CRUCE, SIGA DE FRENTE,PARALELO AL RIO. SIGA 2KM (TENEMOS SEQALIZACION CARTELES FLECHAS DESDE 3.3KM ANTES. TELEFONOS:3603673,3600416 SI USTED TIENE INTERES EN QUE LE ENVIEMOS VISTAS DE NUESTRO LOCAL ENVIENOS UN E-MAILS SOLICITANDO FOTOS E-MAIL: reservacioneslade...@latinmail.com laderasdecalifor...@latinmail.com Si solo desea pasar el dma, hay un consumo mmnimo de S/. 30.00 por persona adulta. El alquiler de parrilla:80.00 soles ( Carbon, utensilios y todo tipo de salsas ) Aceptamos Tarjetas de Cridito ( Master Card, Visa, Diners Club.American Express y Ripley ). Para mayor informacisn y reservaciones smrvase llamar a nuestros telifonos 3603673 - 3600416 Atentamaente jonattan otero LIMA-PERU LAS LADERAS DE CALIFORNIA AGRADECE LA RECEPCION DE NUESTRO E-MAIL. Para no volver a recibir estos mensajes responda por favor escribiendo a: removerlade...@mixmail.com Y SERA REMOVIDO A LA BREVEDAD MUCHAS GRACIAS SI NO SE MOSTRASEN LAS IMAGENES POR FAVOR HACER CLICK EN EL SIGUIENTE LINK: http://perso.gratisweb.com/elpalmo112/empresas.doc [demime 1.01d removed an attachment of type image/jpeg which had a name of retocada1000.jpg]
cvsup/cvsync/anoncvs
Hi, i am goin to set up cvsup/anoncvs/cvsync server, but don't knwo how. Can you help me with configuration of these *cvs* servers? I have already write an e-mail to [EMAIL PROTECTED], but w/o any answer. Thanks for help.
