Posted on 2008-07-04 09:00:00
Tags: FreeBSD
In the last couple of months I have migrated left-over applications on old i386 servers running FreeBSD 4.something to jails on amd64 servers running FreeBSD 6.3. It works fine, it works like a charm, thanks to the 32 bit compatibility and the misc/compat4x port. I could just copy everything in /usr/local/ to the new jail, run ldconfig -32 /usr/local/lib and everything started without problems.
There was only an issue with the ldd(1) command in the base-system:
The man-page of rtld(1) revealed that it could work:[/] root@ed-exigent>ldd `which httpd` ldd: /usr/local/sbin/httpd: can't read program header ldd: /usr/local/sbin/httpd: not a dynamic executable
So ldd(1) had to be educated about the differences in the ELF header for 32 bit and 64 bit ELF objects. Once that was done, no problem at all anymore![/] root@ed-exigent>LD_32_TRACE_LOADED_OBJECTS=1 `which httpd` libm.so.4 => /lib32//libm.so.4 (0x280c8000) libaprutil-1.so.2 => /usr/local/lib/libaprutil-1.so.2 (0x280de000) libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x280f2000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28110000) libapr-1.so.2 => /usr/local/lib/libapr-1.so.2 (0x281fd000) libcrypt.so.3 => /lib32//libcrypt.so.3 (0x2821d000) libpthread.so.2 => not found (0x0) libc.so.6 => /lib32//libc.so.6 (0x28235000) libpthread.so.2 => /usr/lib32/libpthread.so.2 (0x2830d000)
Patches are available at bin/124906, have been commited to HEAD and will be MFCed in a week.
Posted on 2008-07-03 10:40:00
Tags: FreeBSD, FreeBSD ports
When it comes to the FreeBSD Ports collection, the CVS repository and the GNATS bug tracking system, people not always understand how its can be made easier.
For example: Did you know that the URL http://bugs.freebsd.org/12345 would bring you automatically to the PR with number 12345? And did you know that if you want to checkout the directory /ports/x11-wm/fvwm95, all you have to do it cvs co fvwm95 (For an easy Mozilla Firefox and Seamonkey (and probably other browsers) sidebar, visit this page)
So, what is the story about that cvs co fvwm95. The magic for that is stored in the file CVSROOT-ports/modules, it contains a list of all ports and their directories. The file is updated every time a port gets commited, removed or changed from location. At least that is the theory. Adding is done manually via the addport script, but removing and changing locations has been always a manual task.
Recently the caretaker of this file had enough of people whinching when he said they needed to update that file when it changed. So he said that support for it would cease. But but but... That would break at least one of my ways to do things easy!
I can do only one thing now, take control over it myself! So I proposed it to portmgr@, who approved it. The second thing to make is a script which mangles /usr/ports/INDEX to generate a modules file (in the shape I like it).
All that is done now, and the CVSROOT-ports/modules file is now updated once per day. See the CVS webinterface for the last update!
Posted on 2008-06-03 19:00:00
Tags: FreeBSD, FreeBSD ports
Since a couple of weeks Internode has a Sourceforge mirror, which traffic is free of charge for Internode customers.
If you want to prefer it in your ports configuration, add this to /etc/make.conf:
MASTER_SITE_SOURCEFORGE= \ http://internode.dl.sourceforge.net/sourceforge/%SUBDIR%/ MASTER_SORT?= internode.dl.sourceforge.net mirror.internode.on.net .au
Posted on 2008-05-13 23:00:00
Tags: IPv6, FreeBSD, Networking
Victory! Tonight I managed to get the nat6to4 daemon working. Remember what went wrong yesterday:
IPv6 packet does not go from the nat6to4 daemon into divert. What?!?!?Yes, that would have worked in one go if I actually had pushed the data in the right IPv6 socket instead of in the wrong IPv4 socket. It happens, specially when you are copying whole functions around.
As a demo:
That is pretty uninteresting for the naked eye, but the thing is that the Allegro-Software-RomPager doesn't support IPv6, it's mapped via the nat6to4 gateway.[~] edwin@freefall>telnet 2001:5c0:8fff:ffff::c3 80 Trying 2001:5c0:8fff:ffff::c3... Connected to 2001:5c0:8fff:ffff::c3. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Date: Tue, 13 May 2008 14:10:23 GMT Expires: Thu, 26 Oct 1995 00:00:00 GMT Last-Modified: Tue, 13 May 2008 14:10:23 GMT Pragma: no-cache Content-Length: 32 Server: Allegro-Software-RomPager/4.34 Connection closed by foreign host.
So, my nat6to4 daemon works for mapping the TCP or UDP payload of basic IPv6 packets (single header, nothing fancy) onto IPv4 packets: Now I can make all basic services on my jails (webservers, LDAP servers, DNS servers, POP and IMAP servers) available via IPv6.
Now I have to put netinet6/ip6_divert.c into a shape so that it gets accepted by the FreeBSD project, right now there are too many things commented out because I didn't know what they are for. Yes, I feel like an apprentice magician left alone with a hand full of scrolls and asked to find out if they are interesting.
Patches for FreeBSD 6.3 are available from
http://people.freebsd.org/~edwin/freebsd63-ip6divert-20080513.patch.
The nat6to4d is available from
http://people.freebsd.org/~edwin/nat6to4d-20080513.c.
And the ipfw rules:
01005 606 245695 divert 8664 ip from any to 192.168.253.2 01006 452 33304 allow ipv6-icmp from any to me6 via tun1 01006 517 51742 divert 8666 ip6 from any to me6 via tun1 65535 79349 20349420 allow ip from any to any
Posted on 2008-05-12 10:00:00
Tags: IPv6, FreeBSD, Networking
A small update:
sockstat still doesn't show it though...nat6to4d 2578 root 3u IPv6 0xc1df8ec4 0t0 DIVERT *:8666 nat6to4d 2578 root 4u IPv4 0xc1dfaec4 0t0 DIVERT *:8664
struct sockaddr_div {
uint8_t div_len;
sa_family_t div_family; /* AF_INET / AF_INET6 */
in_port_t div_cookie; /* was: sin_port */
char div_iface[8];
struct in6_addr div6_addr; /* IPv6 address */
struct in_addr div4_addr; /* IPv4 address */
};So what works and what doesn't?
But that is an adventure for later when I have some spare time again... work and two kids, that doesn't leave much time adventures like this (except between 22:00 and 01:00 which is very bad for everybody)
Posted on 2008-05-06 10:00:00
Tags: IPv6, FreeBSD, Networking
This whole IPv6 Divert idea seems to be a little bit optimistic now. As all new technology (I wouldn't call IPv6 new technology, but still) not everything you have available now is supported in it.
So, how far did we get?
So, this is getting trickier and trickier for an userland guy like me to experiment with on a sunday afternoon... But I'm not going to give up! (yet)
On the other hand, an interesting paper by Dr. Goto (I'm not kidding) and friends available at IPV4/V6 NETWORK EMULATOR USING DIVERT SOCKET says:
I have asked him if he wanted to share his code but haven't heard anything back from him.[...] We have ported divert socket to IPv6 by adding about 1000 lines of C program code either on FreeBSD and Linux kernel for this research. [...]
Posted on 2008-05-01 08:00:00, modified on 2008-06-06 20:00:00
Tags: Networking, FreeBSD
Thanks to my job, or cursed by my job sometimes, I have access to a 3G modem of Three Mobile. It works fine in areas where there is Three Mobile coverage, outside these areas were we are roaming (and probably on the Telstra 3G network) there are interesting issues with the IPCP phase (IP Confirguration Protocol) of PPP which make the PPP setup fail.
So what works and what doesn't? According to the PPP manual, this is what we should see:
The first two Ps become capitals, but the third one doesn't when we are roaming.ppp ON awfulhak> # No link has been established Ppp ON awfulhak> # We've connected & finished LCP PPp ON awfulhak> # We've authenticated PPP ON awfulhak> # We've agreed IP numbers
What do the logs say? The short version of a successful handshake is:
The full log is at the end of this writeup.IPCP: FSM: Using "deflink" as a transport IPCP: deflink: State change Initial --> Closed IPCP: deflink: LayerStart. IPCP: deflink: SendConfigReq(1) state = Closed IPCP: deflink: State change Closed --> Req-Sent IPCP: deflink: RecvConfigNak(1) state = Req-Sent IPCP: deflink: SendConfigReq(2) state = Req-Sent IPCP: deflink: RecvConfigNak(2) state = Req-Sent IPCP: deflink: SendConfigReq(3) state = Req-Sent IPCP: deflink: RecvConfigReq(0) state = Req-Sent IPCP: deflink: SendConfigNak(0) state = Req-Sent IPCP: deflink: RecvConfigRej(3) state = Req-Sent IPCP: deflink: SendConfigReq(4) state = Req-Sent IPCP: deflink: RecvConfigReq(1) state = Req-Sent IPCP: deflink: SendConfigAck(1) state = Req-Sent IPCP: deflink: State change Req-Sent --> Ack-Sent IPCP: deflink: RecvConfigNak(4) state = Ack-Sent IPCP: deflink: SendConfigReq(5) state = Ack-Sent IPCP: deflink: RecvConfigAck(5) state = Ack-Sent IPCP: deflink: State change Ack-Sent --> Opened
The short version of an unsuccessful handshake is:
The full log is at the end of this writeup.IPCP: FSM: Using "deflink" as a transport IPCP: deflink: State change Initial --> Closed IPCP: deflink: LayerStart. IPCP: deflink: SendConfigReq(1) state = Closed IPCP: deflink: State change Closed --> Req-Sent IPCP: deflink: RecvConfigNak(1) state = Req-Sent IPCP: deflink: SendConfigReq(2) state = Req-Sent IPCP: deflink: RecvConfigNak(2) state = Req-Sent IPCP: deflink: SendConfigReq(3) state = Req-Sent IPCP: deflink: RecvConfigNak(3) state = Req-Sent IPCP: deflink: SendConfigReq(4) state = Req-Sent IPCP: deflink: RecvConfigNak(4) state = Req-Sent IPCP: deflink: SendConfigReq(5) state = Req-Sent IPCP: deflink: RecvConfigNak(5) state = Req-Sent IPCP: deflink: SendConfigReq(6) state = Req-Sent IPCP: deflink: RecvConfigNak(6) state = Req-Sent IPCP: deflink: SendConfigReq(7) state = Req-Sent IPCP: deflink: RecvConfigNak(7) state = Req-Sent IPCP: deflink: SendConfigReq(8) state = Req-Sent IPCP: deflink: RecvConfigNak(8) state = Req-Sent IPCP: deflink: SendConfigReq(9) state = Req-Sent IPCP: deflink: RecvConfigNak(9) state = Req-Sent IPCP: deflink: SendConfigReq(10) state = Req-Sent IPCP: deflink: RecvConfigNak(10) state = Req-Sent IPCP: deflink: SendConfigReq(11) state = Req-Sent IPCP: deflink: SendTerminateReq(11) state = Req-Sent IPCP: deflink: State change Req-Sent --> Closing IPCP: deflink: RecvTerminateAck(11) state = Closing IPCP: deflink: LayerFinish. IPCP: deflink: State change Closing --> Closed IPCP: deflink: RecvConfigNak(11), dropped (expected 12)
If anybody has managed to setup a successful PPP connection on the 3G network of anybody but Three Mobile can send me some logs, I would be very happy to see if I can fix things.
Update According to John Marshall, sending a string similar to this:
could resolve the issue. Next time when I'm in the roaming-zone I'll try it!AT+CGDCONT=1,"IP","telstra.internet"
Here are the full logs:
This is the IPCP part of a successful handshake
ppp[1098]: tun0: Phase: bundle: Network ppp[1098]: tun0: IPCP: FSM: Using "deflink" as a transport ppp[1098]: tun0: IPCP: deflink: State change Initial --> Closed ppp[1098]: tun0: IPCP: deflink: LayerStart. ppp[1098]: tun0: IPCP: deflink: SendConfigReq(1) state = Closed ppp[1098]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1098]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression ppp[1098]: tun0: IPCP: PRIDNS[6] 202.124.76.66 ppp[1098]: tun0: IPCP: SECDNS[6] 255.255.255.255 ppp[1098]: tun0: IPCP: deflink: State change Closed --> Req-Sent ppp[1098]: tun0: LCP: deflink: RecvProtocolRej(2) state = Opened ppp[1098]: tun0: LCP: deflink: -- Protocol 0x80fd (Compression Control Protocol) was rejected! ppp[1098]: tun0: CCP: deflink: State change Req-Sent --> Stopped ppp[1098]: tun0: IPCP: deflink: RecvConfigNak(1) state = Req-Sent ppp[1098]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1098]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1098]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1098]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1098]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1098]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1098]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1098]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1098]: tun0: IPCP: deflink: SendConfigReq(2) state = Req-Sent ppp[1098]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1098]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression ppp[1098]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1098]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1098]: tun0: IPCP: deflink: RecvConfigNak(2) state = Req-Sent ppp[1098]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1098]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1098]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1098]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1098]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1098]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1098]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1098]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1098]: tun0: IPCP: deflink: SendConfigReq(3) state = Req-Sent ppp[1098]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1098]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression ppp[1098]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1098]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1098]: tun0: IPCP: deflink: RecvConfigReq(0) state = Req-Sent ppp[1098]: tun0: IPCP: [EMPTY] ppp[1098]: tun0: IPCP: deflink: SendConfigNak(0) state = Req-Sent ppp[1098]: tun0: IPCP: IPADDR[6] 10.0.0.2 ppp[1098]: tun0: IPCP: deflink: RecvConfigRej(3) state = Req-Sent ppp[1098]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression ppp[1098]: tun0: IPCP: deflink: SendConfigReq(4) state = Req-Sent ppp[1098]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1098]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1098]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1098]: tun0: IPCP: deflink: RecvConfigReq(1) state = Req-Sent ppp[1098]: tun0: IPCP: [EMPTY] ppp[1098]: tun0: IPCP: deflink: SendConfigAck(1) state = Req-Sent ppp[1098]: tun0: IPCP: [EMPTY] ppp[1098]: tun0: IPCP: deflink: State change Req-Sent --> Ack-Sent ppp[1098]: tun0: IPCP: deflink: RecvConfigNak(4) state = Ack-Sent ppp[1098]: tun0: IPCP: IPADDR[6] 119.11.8.120 ppp[1098]: tun0: IPCP: IPADDR[6] changing address: 0.0.0.0 --> 119.11.8.120 ppp[1098]: tun0: IPCP: PRIDNS[6] 202.124.68.130 ppp[1098]: tun0: IPCP: SECDNS[6] 202.124.76.66 ppp[1098]: tun0: IPCP: Primary nameserver set to 202.124.68.130 ppp[1098]: tun0: IPCP: Secondary nameserver set to 202.124.76.66 ppp[1098]: tun0: IPCP: deflink: SendConfigReq(5) state = Ack-Sent ppp[1098]: tun0: IPCP: IPADDR[6] 119.11.8.120 ppp[1098]: tun0: IPCP: PRIDNS[6] 202.124.68.130 ppp[1098]: tun0: IPCP: SECDNS[6] 202.124.76.66 ppp[1098]: tun0: IPCP: deflink: RecvConfigAck(5) state = Ack-Sent ppp[1098]: tun0: IPCP: IPADDR[6] 119.11.8.120 ppp[1098]: tun0: IPCP: PRIDNS[6] 202.124.68.130 ppp[1098]: tun0: IPCP: SECDNS[6] 202.124.76.66 ppp[1098]: tun0: IPCP: deflink: State change Ack-Sent --> Opened ppp[1098]: tun0: IPCP: deflink: LayerUp.
This is the IPCP part of a unsuccessful handshake
ppp[1661]: tun0: Phase: bundle: Network ppp[1661]: tun0: IPCP: FSM: Using "deflink" as a transport ppp[1661]: tun0: IPCP: deflink: State change Initial --> Closed ppp[1661]: tun0: IPCP: deflink: LayerStart. ppp[1661]: tun0: IPCP: deflink: SendConfigReq(1) state = Closed ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: State change Closed --> Req-Sent ppp[1661]: tun0: LCP: deflink: RecvProtocolRej(2) state = Opened ppp[1661]: tun0: LCP: deflink: -- Protocol 0x80fd (Compression Control Protocol) was rejected! ppp[1661]: tun0: CCP: deflink: State change Req-Sent --> Stopped ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(1) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(2) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(2) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(3) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(3) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(4) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(4) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(5) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(5) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(6) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(6) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(7) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(7) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(8) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(8) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(9) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(9) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(10) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(10) state = Req-Sent ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: PRINBNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK?? ppp[1661]: tun0: IPCP: SECNBNS[6] 10.11.12.14 ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK?? ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13 ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14 ppp[1661]: tun0: IPCP: deflink: SendConfigReq(11) state = Req-Sent ppp[1661]: tun0: IPCP: IPADDR[6] 0.0.0.0 ppp[1661]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression ppp[1661]: tun0: IPCP: PRIDNS[6] 10.11.12.13 ppp[1661]: tun0: IPCP: SECDNS[6] 10.11.12.14 ppp[1661]: tun0: Command: /dev/ttyp1: quit ppp[1661]: tun0: IPCP: deflink: SendTerminateReq(11) state = Req-Sent ppp[1661]: tun0: IPCP: deflink: State change Req-Sent --> Closing ppp[1661]: tun0: IPCP: deflink: RecvTerminateAck(11) state = Closing ppp[1661]: tun0: IPCP: deflink: LayerFinish. ppp[1661]: tun0: IPCP: Connect time: 11 secs: 0 octets in, 0 octets out ppp[1661]: tun0: IPCP: 0 packets in, 0 packets out ppp[1661]: tun0: IPCP: total 0 bytes/sec, peak 0 bytes/sec on Thu Apr 24 13:39:49 2008 ppp[1661]: tun0: IPCP: deflink: State change Closing --> Closed ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(11), dropped (expected 12) ppp[1661]: tun0: Phase: bundle: Terminate
Posted on 2008-03-25 09:00:09, modified on 2008-03-25 09:00:00
Tags: FreeBSD, zoneinfo
Commit of the day for src/share/zoneinfo:
This is availabe in FreeBSD > 7.0, > 6.3 and > 5.5 and in the ports collection (as misc/zoneinfo).Changes: - Calcutta -> Kolkata - Iraq DST changes - Syria DST changes - Saigon -> Ho_Chi_Minh - Cuba DST changes - New area America/Argentina/San_Luis
Posted on 2008-03-10 09:00:09, modified on 2008-03-10 09:00:00
Tags: FreeBSD, zoneinfo
Commit of the day for src/share/zoneinfo:
This is availabe in FreeBSD > 7.0, > 6.3 and > 5.5 and in the ports collection (as misc/zoneinfo).- Chilis DST has been extended for 3 weeks. - No leapsecond in 2008
Posted on 2008-01-31 20:00:00
Tags: Networking, tftp, FreeBSD
It all started when we got some new routers, which told me the following when trying to upload configuration or download images from it: The TFTP server doesn't support the blocksize option.
My curiousity was triggered, it took me some reading of RFCs and other documentation to find out what was possible and what could be done. Was plain TFTP very simple in its handshake, TFTP with options was kind of messy because of its backwards capability: The first packet returned could either be an acknowledgement of options, or the first data packet.
Going through the source code of src/libexec/tftpd and going through the code of src/usr.bin/tftp showed that there was a lot of duplicate code, and the addition of options would only increase the amount of duplicate code. After all, both the client and the server can act as a sender and receiver.
At the end, it ended up with a nearly complete rewrite of the tftp client and server. It has been tested against the following TFTP clients and servers:
It supports the following RFCs:
It supports the following unofficial TFTP Options as described at http://www.compuphase.com/tftp.htm:
From the tftp program point of view the following things are changed:
If you try this tftp/tftpd implementation, please let me know if it works (or doesn't work) and against which implementaion so I can get a list of confirmed working systems.
For now, the new implementation can be found at as a port in net/freebsd-tftp until it has been imported back into the FreeBSD base system.
Posted on 2008-01-01 18:00:00, modified on 2008-01-06 19:00:00
Tags: FreeBSD, zoneinfo
Commit of the day for src/share/zoneinfo:
MFV of tzdata2007k Timezone data changes in this import: - Add Argentinian DST changes - Place SJH in the right location
This will be availabe in FreeBSD >= 7.0, >= 6.3 and >5.5 and in the ports collection (as misc/zoneinfo).
Updated: MFCed into RELENG_7_0 and RELENG_6_3 so it will be available for the releases of 6.3 and 7.0.
Posted on 2007-12-26 17:00:00
Tags: FreeBSD, IPC
Thanks to a submmited patch of Callum Gibson the ipcrm(1) program now has the capabilities to wipe all unused shared memory segments, message queues and semaphore sets. You can either chose to specify the individually (e.g. only the message queues, or only the shared memory segments) or just wipe them all with the -W option.
This will be availabe in FreeBSD >7.0, >6.3 and >5.5.
Posted on 2007-12-14 21:00:00, modified on 2007-12-17 07:30:00
Tags: Huawei E220, FreeBSD, Networking
I'm the lucky owner of a Huawei E220 G3 USB modem. For certain degrees of lucky that is: Getting it to work has been an interesting challenge.
The E220 is by default (FreeBSD 6.3-BETA) recognized as an umass(4) (USB Mass Storage Device) device. That's true, there is a memory disk in it. It is recognized as /dev/cd0 and you can mount it with mount_cd9660 /dev/cd0 /mnt, giving you 10 megabytes of space.
But that is not what you bought the E220 for. You want to use it
as a modem. You need to change a couple things in your kernel to
get it all working.
First, add a line to /sys/dev/usb/usbdevs:
See the
FreeBSD PR usb/118686 for a full patch.
And to /sys/dev/usb/usba.c:
/* HP products */
product HP2 C500 0x6002 PhotoSmart C500
/* HUAWEI products */
product HUAWEI MOBILE 0x1001 Huawei Mobile
+product HUAWEI E220 0x1003 Huawei E220 HSDPA USB Modem
/* IBM Corporation */
product IBM USBCDROMDRIVE 0x4427 USB CD-ROM Drive
{ USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3G },
/* Option GlobeTrotter 3G QUAD */
{ USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3GQUAD },
/* Huawei Mobile */
{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_MOBILE },
+{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_E220 },
{ 0, 0 }
};
Second, you have to disable the umass(4) device from your kernel configuration and rebuild a new kernel. Will this break things? Most likely, specially when you have USB disks and sticks. But you will load it as a module, which will undo the damage you just did to it. In your /boot/loader.conf, add the following lines:
ubsa_load="YES"
umass_load="YES"
ubsa(4) is the USB support for Belkin serial adapter. That sounds more like a modem. Next, reboot the machine and see if all modules are loaded correctly:
# kldstat
Id Refs Address Size Name
1 20 0xc0400000 72e17c kernel
2 1 0xc0b2f000 e6a4 if_iwi.ko
3 3 0xc0b3e000 2f9c firmware.ko
4 1 0xc0b41000 6cdc ugen.ko
5 1 0xc0b48000 75b4 umass.ko
6 1 0xc0b50000 7958 ng_ubt.ko
7 2 0xc0b58000 cb78 netgraph.ko
8 1 0xc0b65000 2ef0 ubsa.ko
9 2 0xc0b68000 4374 ucom.ko
10 1 0xc0b6d000 5c304 acpi.ko
11 1 0xc4868000 30000 iwi_bss.ko
Next, plugin your E220 and see what happens:
ucom0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
ucom0: Could not find interrupt in
device_attach: ucom0 attach returned 6
Yes! No! Something is wrong. But a little bit of finger skill will
resolve it:
At the USB modem side of the USB cable (not the computer side!),
carefully pull the cable from the modem and when you see this on
your screen, plug it back in:
ucom0: at uhub1 port 1 (addr 2) disconnected
ucom0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
It's loaded! If it doesn't work at the first go, try it a couple
of times more. Once you are without the dreaded "Couldn't find
interrupt in" message you are a happy person.
Check /dev/cuaaU0, it exists! If you have comms/minicom installed, you can do this:
OK
ATI
Manufacturer: huawei
Model: E220
Revision: 11.117.06.00.100
IMEI: 358191018517800
+GCAP: +CGSM,+DS,+ES
OK
And if you dial out, you will end up with a whooping 7.2Mbps connection;
OK
ATDT *90#
CONNECT 7200000
Now it is time to train ppp(1). Add this to your /etc/ppp/ppp.conf:
three:
set device /dev/cuaU0
set speed 57600
set phone *99\#
set authname
set authkey
set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0
set vj slotcomp off
add default HISADDR
And dial:
$ ppp three
ppp> dial
Ppp>
PPp>
That's not good, there should be three capital P's... Going through the PPP log, you will see that the IPCP layer doesn't get initialized properly. Why? No idea. How to resolve it? Put your USB modem in a windows machine, run it once there and put it back into your FreeBSD machine. Why? No idea. It works. The USB modem didn't work with under MacOS/X neither until I did this trick. Why? No idea. It works.
Dial again:
$ ppp three
ppp> dial
Ppp>
PPp>
PPP>
$ ifconfig tun0
tun0: flags=8051 mtu 1500
inet 119.11.32.164 --> 10.0.0.2 netmask 0xffffffff
Opened by PID 22997
$ ping www.freebsd.org
PING www.freebsd.org (69.147.83.33): 56 data bytes
64 bytes from 69.147.83.33: icmp_seq=0 ttl=48 time=477.662 ms
64 bytes from 69.147.83.33: icmp_seq=1 ttl=51 time=416.606 ms
^C
--- www.freebsd.org ping statistics ---
3 packets transmitted, 2 packets received, 33% packet loss
round-trip min/avg/max/stddev = 416.606/447.134/477.662/30.528 ms
Your console and /var/log/messages will be spammed with "kernel: ucom0: usba_request: STALLED" messages for some reason, but it works.
Posted on 2007-12-06 17:00:00, modified on 2007-12-06 19:30:00
Tags: FreeBSD
At Statistics for FTP FreeBSD mirrors I have made an overview of how good the FreeBSD FTP mirrors are. Not a full overview, just for the ISO images directories, but it will give an indication of the quality of the mirroring.
For Australia is shows that at this moment in time ftp3.au.freebsd.org, or mirror.pacific.net.au, is the only one who is nicely mirroring everything, the rest is running behind or doing partly mirroring.
Scripts are available from the URL linked to above.
Posted on 2007-12-04 10:00:00, modified on 2008-01-06 19:00:00
Tags: FreeBSD, zoneinfo, iso3166
Commit of the day for src/share/zoneinfo:
and of src/share/misc/iso3166:MFV of tzdata2007j Timezone data changes in this import: - Add America/St_Barthelemy (BL) and America/Marigot (MF) - Venezuela will move to -4:30 on 9 December 2007 instead of 31 December 2007
Update with data from Newsletter VI-1 2007-09-21: - Added SAINT BARTHELEMY (BL) and SAINT MARTIN (MF).
This will be availabe in FreeBSD >7.0, >6.3 and >5.5 and in the ports collection (as misc/zoneinfo) once the ports freeze has been lifted or use ports/118409 to update your system earlier.
Note: the iso3166 and the zoneinfo updates are MFCed into RELENG_7_0 and RELENG_6_3 so it will be available for the releases of 7.0 and 6.3.
Posted on 2007-11-26 10:00:00
Tags: FreeBSD, tftp
Commit of the day for tftpd(8):
Add the -W options, which acts the same as -w but will generate unique names based on the submitted filename, a strftime(3) format string and a two digit sequence number. By default the strftime(3) format string is %Y%m%d (YYYYMMDD), but this can be changed by the -F option.
What does this mean? That you don't have to worry about overwriting your precious previous saved router configuration files:
[/tftpboot] root@tftp>ls -al -rw-r--r-- 1 nobody wheel 44048 Jun 22 08:52 hs2-bd8806.20070622.00 -rw-r--r-- 1 nobody wheel 45973 Jul 21 17:24 hs2-bd8806.20070721.00 -rw-r--r-- 1 nobody wheel 49140 Oct 4 21:49 hs2-bd8806.20071004.00 -rw-r--r-- 1 nobody wheel 49176 Oct 4 21:53 hs2-bd8806.20071004.01 -rw-r--r-- 1 nobody wheel 49177 Oct 4 21:54 hs2-bd8806.20071004.02
This will be availabe in FreeBSD >7.0, >6.3 and >5.5.
Patches will be available from src/libexec/tftpd/
in revisions:
Posted on 2007-05-18 10:00:00
Tags: Adventures, FreeBSD, HP
Today for the first time in my life I had troubles setting up a normal FreeBSD machine due to the geometry of the disk. The machine has a Raid 6i card in it, and there are four 147Gb disks in a RAID5 configuration.
The device gets detected as:
da0: 420029MB (860220400 512 byte sectors: 255H 32S/T 65535CFdisk complains about it:
A geometry of 105419/255/32 for da0 is incorrect.and picks:
DISK Geometry: 53546 cyls/255 heads/63 sectors = 860216490 sectors (420027MB)
Installing FreeBSD on that geometry goes without a problem. But at a reboot, it doesn't work anymore. Pressing F1 for FreeBSD at the bootmanager doesn't work, it just beeps.
Luckely Darius on #bsddev knew how to resolve this:
It works!<Darius> also, can you get to the loader prompt on the CD after you have installed and type.. <Darius> unload <aDrius> set currdev=disk1s1a: <aDrius> boot -s <Darius> then run boot0cfg /dev/da0
Posted on 2007-05-02 17:00:00
Tags: FreeBSD, RSS
Today is a sad day in the world of podcasting. Well, for FreeBSD that is. It seems that the FreeBSD For All podcast has disappeared from the internet. It was one only user-driven FreeBSD related podcast. Copies of the show can still be found at the PodcastDirectory.com, but not sure how much longer they will be there.
Posted on 2007-04-24 11:44:00
Tags: FreeBSD, RSS
I have reworked the implementation of the FreeBSD Multimedia Resources List. From a PHP script which parses everything when a webbrowser asks for it, I know have a Perl script which creates it once and the rest is static.
New features are tags in the articles and it also has a flexible design so it can be very easy modified for the different BSDs:
Unfortunately, the names of the files have changed a little bit to incorperate this:
With these new features I hope that the list will get incorperated in the websites of the varies *BSDs so that the list gets wider fame and I don't have to go from "If I only knew that this presentation was available three months ago..."
Posted on 2006-12-11 09:04:18, modified on 2006-12-11 11:42:03
Tags: FreeBSD, DNS
I have been plagued by this error in some of my jails for a long time:
$ dig foo.bar ;; reply from unexpected source: 202.83.178.125#53, expected 127.0.0.1#53
telnet itself works fine, it's just that dig and friends give this strange error. What is also strange is that the tcpdump output doesn't reflect the settings in /etc/resolv.conf:
$ cat /etc/resolv.conf search barnet.com.au server 202.83.176.1
And the tcpdump output:
# tcpdump -ni lo0 port 53 11:28:45.204241 IP 202.83.178.125.57276 > 202.83.178.125.53: 15750 A? www.ibm.com. (29) 11:28:45.218305 IP 202.83.178.125.53 > 202.83.178.125.57276: 15750- 0/4/4 (203)
Of course this was a configuration issue. In /etc/resolv.conf, the right statement is nameserver, not server. But the resolver in the jail looked through the /etc/resolv.conf of the host which contains 127.0.0.1.
But the final question is: Where does it get 202.83.178.125 from? It is the IP address of the jail, to which 127.0.0.1 silently gets translated to. But the resolver still expects it to come from the 127.0.0.1 number, and is for that reason throwing the warning.
Posted on 2006-08-19 20:55:45, modified on 2006-08-19 21:36:18
Tags: FreeBSD, RSS
I became a little bit tired of giving out the same URLs to everybody each time somebody asked for a list with podcasts/vodcasts etc related to FreeBSD. So I made the FreeBSD Multimedia Resources list. See http://www.mavetju.org/unix/multimedia.php for more information, and there is an RSS feed for it too!
Posted on 2006-03-17 10:31:16, modified on 2006-03-17 11:16:56
Tags: Computers, Citrix, FreeBSD
At work we got a new toy: a Citrix MetraFrame Presentation Manager. In reality it is nothing more than a frontend for a Windows session, like you can get with RealVNC or Remote Desktop. Well, the difference is that more than one person can use it at the same time, and they all have their own desktop and settings. Not even a desktop, just a bunch of icons of pre-installed programs. Anyway, to the FreeBSD story.
Access to the MetaFrame website is easy, just login with your windows username and password. But then, it says "Your client platform is not supported.". This is a false alarm, but confusing.
For the general population, MetaFrame automatically picks the Java client. But not for the FreeBSD machines. At the top right of the Applications window there is a button to customize the user preferences. Client on the Client Preferences settings link. There you can choose between "Local client" and "Client for Java".
"Client for Java" forces the website to use the Java client, just like the general population gets. Works like a charm.
For "Local client", you need to install net/citrix_ica. There are two tweaks I needed to make before it all worked here. First one is that I had to configure a help for .ica files: MIME-Type is application/x-ica, application is /usr/local/bin/wfica. The second one was that I had to add the certificate of our SSL provider to the directory /usr/local/ICAClient/keystore/cacerts (note that the extension should be .crt, and that the name of it should be the same as wfica is complaining about. Use "openssl x509 -noout -text -in foo.crt" to check this).
And it all works now, both ways and without problems.
Posted on 2004-07-02 10:54:01, modified on 2006-01-09 16:29:22
Tags: Networking, FreeBSD
At BarNet, our backup link to the internet goes via a different ISP which is charged per megabyte. Being the backup link, this normally doesn't give much problems. Except when we suddenly got a nasty bill for it. Time for some investigation... (read on)
At this moment, we have say four class C networks (192.168.0.0/24 - 192.168.3.0/24). The first two are allocated, the last two are in use for later. Our IP space is part of the IP space of the backup ISP. Our default gateway is pointing to our normal ISP, and we route the IP space of the backup ISP directly to our backup ISP. Or in a picture:
0.0.0.0/0 -> normal ISP 192.168.0.0/16 -> backup ISP 192.168.0.0/24 -> LAN A 192.168.1.0/24 -> LAN B
What happens when a packet comes in for 192.168.0.1? It gets forwarded to the LAN A. What happens when a packet for 192.168.1.1 comes in? It gets forwarded to the LAN B. And what happens when a packet for 192.168.2.1 comes in? The network 192.168.2.0/24 is not in the routing table, so it takes the next smallest one: 192.168.0.0/16. And the packet goes happily on its way to the backup ISP. But then, it gets send back to us, because the backup ISP knows that 192.168.2.0/24 is on our network. It keeps bouncing between the backup ISP and us until its TTL has expired. Each other bounce is charged to us...
The solution is to add an entry for all our networks in the routing table of one of the machines which gets null-routed: routed into a "network"-device which just discards all packets. Don't go playing with firewall rules, that will only cause problems later when the spare IP space gets used and things suddenly don't work anymore and nobody knows why.
On FreeBSD, the discard device is called disc(4). Just kldload if_disc and you can ifconfig ds0. An IP address is not necessary (trying to add one on FreeBSD 4.7 causes the machine to panic, but with 4.10 it worked). In your /boot/loader.conf, add a line with if_disc_load="YES". In your /etc/rc.conf, add a line with cloned_interfaces="ds0". And as the last one, add a line to your /etc/rc.conf with route_discard="192.168.0.0/22 -interface ds0".
From that moment, your routing table will look like:
0.0.0.0/0 -> normal ISP 192.168.0.0/16 -> backup ISP 192.168.0.0/22 -> ds0 192.168.0.0/24 -> LAN A 192.168.1.0/24 -> LAN B
and there will be no more billing for unwanted traffic from the backup ISP!
Posted on 2004-03-23 13:52:12, modified on 2006-01-09 16:29:21
Tags: Computers, FreeBSD
Recently I changed two things on my computer. 1. I upgraded to FreeBSD 5.2.1 and 2. I installed a bigger harddisk.
When using the soundcard (playing MP3s, listening to the radio, watching movies), the sound got bargled (hickupped, prrrrrtzed, whatever you call it) for a split second, after which it continued as normal.
Annoying, specially if you are singing along. Guido van Rooij (former collegue, fellow FreeBSD user etc) told me to change the buffersize on the sound card to 16Kb:
[~] edwin@k7>sysctl hw.snd.pcm0.buffersize hw.snd.pcm0.buffersize: 16384
To do this, requires a change in /boot/device.hints:
[~] edwin@k7>grep pcm /boot/device.hints hint.pcm.0.buffersize=16384
and a reboot. Since this change my MP3s play smoothly.
Posted on 2004-03-06 15:23:22, modified on 2006-01-09 16:29:21
Tags: Computers, FreeBSD
[~] root@k7>sysctl hw.snd.pcm0.vchans hw.snd.pcm0.vchans: 0
If you set this to a higher number (I have four), multiple applications can access the /dev/dsp device at the same time:
[~] edwin@k7>lsof -n | grep dsp mplayer 16352 edwin 9w VCHR 30,131075 0t40194048 218 /dev/dsp0.2 xmms 99819 edwin 10w VCHR 30,3 0t22636544 34 /dev/dsp0.0
Finally I can play games and listening to the radio at the same time!
Posted on 2004-01-22 11:47:45, modified on 2006-01-09 16:29:21
Tags: Computers, FreeBSD
Up to now, I always upgraded my FreeBSD computers via the mini-ISO cdroms provided by the FreeBSD team. Last week, due to circumstances, I had to upgrade them via cvsup and to build the new OS from scratch. A small step for me, a huge step for ME!
At BarNet, there are about eight remote computers. On uninhabited places, like in cupboards, behind the copier, three meters above the floor and so on. Not easily reachable :-)
Also, the computers were running a huge range of OS versions, ranging from FreeBSD 4.2 to FreeBSD 4.9. With matching the OS version with the date the OS version was released you could figure out when the machine came into operation.
And the last thing was that we are going to provide ADSL backup features, which means that when the primary link fails, the traffic will go via a slower link. And zebra, the routing daemon we were going to use, doesn't really work with FreeBSD versions lower than 4.6.
Was that now so difficult? No. So why have I struggled in the last seven years with cdroms? Must be because I had never done it before.
Of course things can go wrong. And will go wrong.
During one night I had xterms open to all machines which had to be upgraded (erm... all of them), running the make buildXXXX. With -j4, the load on the machine will swing between 5 and 10. We use nagios to monitor the systems, and it complained that their loads was too high. And since I'm not the only one receiving these alerts, I got phonecalls saying "what's wrong, what's wrong?". Inform your fellow people before you start.
First machine I upgraded went without a glitch. The second machine I did didn't come back up. So far for a foolproof solution. When I went to the console (next day early in the morning): fsck had failed. With other words, the harddisk is broken.
Two machines which had been given more networks cards recently didn't come back properly. It seemed the network cards were configured properly, but and the ifconfig_ statements added to /etc/rc.conf, but they had their (old, obsolete) "network_interfaces" variable in /etc/rc.conf not updated. A manual ifconfig and editing of /etc/rc.conf fixed it. (Don't forget to reboot afterwards to see if it works again, or at least restart the DHCP daemon since that daemon doesn't automaticly grabs new interfaces).
From now on, no more binary upgrades anymore for me, just cvsup and make! Yay!