umodem + cdce without ppp?
Hi all I found out my Ericsson F3705g GSM/WCDMA modem can be configured to do all the LCP, auth, IPCP and routing stuff automagically. A couple of AT commands cu (radio on + connect) and a DHCP request on the cdce interface is all it takes to get a working connection. A couple AT commands more are needed to disconnect / disable radio. What is the better way to automate this connecting / disconnecting? Can chat(8) be used outside ppp/pppd? Anything usable by netstart?... Unrelated but someone might care: the ThinkPad's BIOS whines about the card being unsupported, but I managed to get it working. I just need to turn it off and then back on on the BIOS, and not take too long between reboots. acpidumps are equal whether the card is detected or not. TIA Zé -- OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar 5 09:37:46 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8357658624 (7970MB) avail mem = 8126566400 (7750MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries) bios0: vendor LENOVO version 6QET70WW (1.40 ) date 10/11/2012 bios0: LENOVO 3680WE9 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! BOOT SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 2660.45 MHz 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-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 133MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 2660.01 MHz 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 2660.01 MHz 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 5 (application processor) cpu3: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 2660.01 MHz 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 2, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 13 (EXP1) acpiprt3 at acpi0: bus -1 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus -1 (EXP4) acpiprt6 at acpi0: bus 2 (EXP5) acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2 acpitz0 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 not present acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK docked (15) cpu0: Enhanced SpeedStep 2660 MHz: speeds: 2400, 2399, 2266, 2133, 1999, 1866, 1733, 1599, 1466, 1333, 1199 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core Host rev 0x02 vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1280x800 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 3400 MEI rev 0x06 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 Intel 82577LM rev 0x06: msi, address **:**:**:**:**:** ehci0 at pci0 dev 26 function 0 Intel 3400 USB rev 0x06: apic 1 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at
Re: umodem + cdce without ppp?
On 2014-03-13, Zé Loff zel...@zeloff.org wrote: Hi all I found out my Ericsson F3705g GSM/WCDMA modem can be configured to do all the LCP, auth, IPCP and routing stuff automagically. A couple of AT commands cu (radio on + connect) and a DHCP request on the cdce interface is all it takes to get a working connection. A couple AT commands more are needed to disconnect / disable radio. There is no LCP/IPCP etc. with cdce, the GSM/3G terminal just acts as an ethernet-like interface instead of acting like a PPP interface. (With PPP, the session is with the terminal *not* the mobile network). What is the better way to automate this connecting / disconnecting? Can chat(8) be used outside ppp/pppd? Yes it can. Anything usable by netstart?... Netstart won't try to configure cdce0 unless the device exists when it's run .. So you could do either of these: 1. modify /etc/rc to send the AT commands before netstart is run so that it can find a cdce0 device 2. create hostname.cdce0, accept that it won't be auto configured at startup, and send the AT commands and run /etc/netstart cdce0 from rc.local 3. bodge things by putting shell commands in hostname.em0 or similar 4. just use a script which you run manually to bring up the mobile network. I prefer 1 or 4..
Re: umodem + cdce without ppp?
On Thu, Mar 13, 2014 at 02:15:27PM +, Stuart Henderson wrote: On 2014-03-13, Zé Loff zel...@zeloff.org wrote: Hi all I found out my Ericsson F3705g GSM/WCDMA modem can be configured to do all the LCP, auth, IPCP and routing stuff automagically. A couple of AT commands cu (radio on + connect) and a DHCP request on the cdce interface is all it takes to get a working connection. A couple AT commands more are needed to disconnect / disable radio. There is no LCP/IPCP etc. with cdce, the GSM/3G terminal just acts as an ethernet-like interface instead of acting like a PPP interface. (With PPP, the session is with the terminal *not* the mobile network). Exactly. That's why I was wondering on how to do this (this being modem chatting, connect/disconnect scripts, etc) without resorting to ppp(8). The card handles all the stuff that normally would be ppp(8)'s job, as it implements a bunch of AT commands to set auth, LCP, IPCP, DNS, routing, etc. You can even define 'accounts' with specific combinations of these parameters and then just tell the card to 'enable account X'. It establishes the connection and starts emulating ethernet on the cdce interface (please excuse any wrong terminologu, I'm more or less quoting Sony Ericsson, and I'm no expert on the matter). See [1] and [2] (page 238 onwards) if you're interested. What is the better way to automate this connecting / disconnecting? Can chat(8) be used outside ppp/pppd? Yes it can. Just looked it up more carefully. Standard redirection. Duh. I'm sorry I asked... Anything usable by netstart?... Netstart won't try to configure cdce0 unless the device exists when it's run .. So you could do either of these: 1. modify /etc/rc to send the AT commands before netstart is run so that it can find a cdce0 device cdce0 is immediately available, no problem there 2. create hostname.cdce0, accept that it won't be auto configured at startup, and send the AT commands and run /etc/netstart cdce0 from rc.local Not being autoconfigured isn't a problem. hotplugd can be used to send the radio on command if I don't care much about battery life, and now that I think of it, maybe I can tell ifstated(8) to enable/disable the GSM/3G connection when I manually tell cdce0 to come up/down (disabling the connection is an important part in all this)... I guess this comes close to option 4 below. 3. bodge things by putting shell commands in hostname.em0 or similar 4. just use a script which you run manually to bring up the mobile network. I prefer 1 or 4.. Many thanks! Zé [1] http://www.natisbad.com/E4300/Dell_Wireless_5530_AT_cmd_ref.html [2] http://dl-developer.sonymobile.com/documentation/DW-65054-dg_at_2006--10_r17a.pdf --
Re: Broken links on faq
On 03/12/14 22:35, ropers wrote: On 13 March 2014 00:23, Maurice McCarthy wrote: On the typo http://[url snipped]/faq//faq1.html an extra faq/ is placed ... where it should not be. It isn't really *placed*. If you look at the HTML source, you'll see that the links that (only) *seem* to be acting up in connection with the mistyped URL are just ordinary relative links; e.g.: | Our | a href=../goals.htmlgoals/a place emphasis on correctness, | a href=../security.htmlsecurity/a, standardization, and | a href=../plat.htmlportability/a. It's just that your browser (and my Firefox) seems to --in this context at least-- interpret the // as an extra level in the hierarchy, so the start from www.openbsd.org/faq/ and go one level up to reach www.openbsd.org/ seems to become start from www.openbsd.org/faq// and go one level up to reach www.openbsd.org/faq/ (which doesn't have e.g. a goals.html). The inconsistency arises because on the one hand, the // is accepted as equivalent to / (which is why you're getting a page at all with the mistyped URL), but then on the other hand, the // is parsed as two hierarchy levels. So // counts as 1 on the way *down* the hierarchy, but it counts as 2 on the way back *up*. not exactly. ok, you go to ...faq//faq1.html The OS on the webserver takes you to [htmldocs]/faq//faq1.html. OpenBSD (and I believe most unix-like OSs) ignores the extra slash. ...but your browser doesn't. So...when you click on a href=../goals.htmlgoals/a your browser lops off one slash and submits a url to the server -- http://.../faq/goals.html which is wrong. I'm not actually sure if this behaviour is canonical, and/or whether it's a bug or not, either in Firefox or (also) in the HTTPD. To my naive mind making assumptions that are based on bugger all, the // ought to take you back to the root, but I haven't read the RFC/spec. Maybe someone else knows this off the top of their head? regards, --ropers PS: Okay, so I have at least skimmed parts of https://tools.ietf.org/html/rfc3986#section-3 - but specifically as the question how //s ought to be treated, I'm none the wiser. Apparently the only place the RFC really envisages //s is in front of the authority (domain name part), i.e.after http: or similar. But then the RFC doesn't strictly say that //s were illegal in any other place. If anyone else knows this, I'd be much obliged for cluebat ministrations. It is really much simpler than that. The OP's URL is *WRONG*. Plain and simple. It shouldn't be on the OpenBSD website at all, and it shouldn't be elsewhere, either. It shouldn't have been submitted to the OpenBSD web servers with the expectation of success. The fact that the web server returned something looking useful has to do with what the underlying OS does with double slashes -- just ignores them, but it isn't required/desired/whatever. It is entirely possible to write a web server which would do something totally different with double slashes. So..the fact that relative links against an incorrect URL don't work is not really an issue. If there's an issue here (and I don't believe there is), maybe the webserver should have 404'd on the initial URL. (I saw a discussion recently where the idea came up of increasing donations by by changing 404 errors to 402. Yeah, I had to look it up, too. So I expect everyone who participates in this thread WILL be buying a CD set soon. :) Nick.
'newer' Qlogic HBA support on amd64
Hi, I have a an amd64 server (HP DL360 G5), with an Qlogic FC HBA in it. It appears to be based on the ISP2400 series, and isp man page says the driver only supports up to the ISP2300 series. However the driver appears to try to attach the device irrespective (and fail). Does anyone know how different the 2400 series are, or if there is work in progress to support them ? thanks /Pete Some relevant info below: $ dmesg | grep isp0 isp0 at pci8 dev 0 function 0 QLogic ISP2432 rev 0x02: apic 8 int 17 isp0: Polled Mailbox Command (0x8) Timeout (10us) isp0: Polled Mailbox Command (0x8) Timeout (10us) isp0: Mailbox Command 'ABOUT FIRMWARE' failed (TIMEOUT) # pcidump -v 19:0:0 19:0:0: QLogic ISP2432 0x: Vendor ID: 1077 Product ID: 2432 0x0004: Command: 0147 Status ID: 0010 0x0008: Class: 0c Subclass: 04 Interface: 00 Revision: 02 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 10 0x0010: BAR io addr: 0x5000/0x0100 0x0014: BAR mem 64bit addr: 0xfdff/0x4000 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 103c Product ID: 7040 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 07 Min Gnt: 00 Max Lat: 00 0x0044: Capability 0x01: Power Management 0x004c: Capability 0x10: PCI Express Link Speed: 2.5 / 2.5 GT/s Link Width: x4 / x4 0x0064: Capability 0x05: Message Signaled Interrupts (MSI) 0x0074: Capability 0x03: Vital Product Data (VPD) 0x007c: Capability 0x11: Extended Message Signaled Interrupts (MSI-X) $ dmesg | head OpenBSD 5.3 (GENERIC.MP) #62: Tue Mar 12 18:21:20 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP # sysctl hw hw.machine=amd64 hw.model=Intel(R) Xeon(R) CPU E5420 @ 2.50GHz hw.ncpu=4 hw.byteorder=1234 hw.pagesize=4096 hw.disknames=sd0:20008a7ae6c37c52,cd0: hw.diskcount=2 hw.sensors.cpu0.temp0=37.00 degC hw.sensors.cpu1.temp0=37.00 degC hw.sensors.cpu2.temp0=37.00 degC hw.sensors.cpu3.temp0=37.00 degC hw.sensors.acpitz0.temp0=8.30 degC (zone temperature) hw.sensors.ciss0.drive0=online (sd0), OK hw.cpuspeed=2500 hw.setperf=100 hw.vendor=HP hw.product=ProLiant DL360 G5 hw.physmem=4292161536 hw.usermem=4292136960 hw.ncpufound=4 hw.allowpowerdown=1
Re: 'newer' Qlogic HBA support on amd64
On Thu, Mar 13, 2014 at 18:44, Pete Vickers wrote: Hi, I have a an amd64 server (HP DL360 G5), with an Qlogic FC HBA in it. It appears to be based on the ISP2400 series, and isp man page says the driver only supports up to the ISP2300 series. However the driver appears to try to attach the device irrespective (and fail). Does anyone know how different the 2400 series are, or if there is work in progress to support them ? In 5.5 and later, that's supported by the qle driver. The isp driver is being broken into parts (qlw, qla, qle) depending on generation. I'd try a snapshot. It should work better. And if it doesn't work, we'd like to know.
[ANN] portable cwm 5.5
Hello, today I'm proud to release the second public version of portable cwm 5.5. Portable cwm is a minor modification of the cwm version in OpenBSD CVS with a portable Makefile and a few compatibility features. It has been built successfully on OpenBSD, NetBSD and Linux. This port requires pkg-config, Xft, Xinerama and Xrandr. The included Makefile should work with both GNU make and BSD make. This version actively tracks changes in the OpenBSD CVS repository. Releases are roughly coordinated with OpenBSD releases. The source can be found at https://github.com/chneukirchen/cwm A changelog can be found at https://github.com/chneukirchen/cwm/blob/linux/README http://chneukirchen.org/releases/cwm-5.5.tar.gz http://chneukirchen.org/releases/cwm-5.5.tar.gz.asc Enjoy! -- Christian Neukirchen chneukirc...@gmail.com http://chneukirchen.org 0e21a48b4973beb7ddf265bea48b73b0c39a589e cwm-5.5.tar.gz ca22a0d46981f4683ba68780e45d95cfaa747547 cwm-5.5.tar.gz.asc
