Re: Routing issue with cable modem
I guess no one knew the answer to my original question about getting RCN cable modem (with analog upstream line dialup) to work. So here's a somewhat simplified question. I narrowed the problem down to routing. Cable modem does dial out when I try to ping something on it's subnet (10.17.56.###), however it does not respond to any broadcast ARP queries about location of DNS server. [ ... ] P.S.S. On a side note: it would be very interesting to know how MSWin98 does it's network setup, that it has no trouble using the modem. Have you tried typing "route print" into an MSDOS window, and having Windows simply tell you what its network configuration? I suspect you are incorrectly setting up an asymetric route, since you say that you have zero upchannel through the cable line, and must use an analog dialup, instead... Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
HELP
HELP To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPFW bug/incoming TCP connections being let in.
I had blocked incoming TCP connections coming into my network using IPFW, and I noticed that my brother was able to establish a Napster connection, even though I had blocked it earlier. *sigh* Thanks to Guy Helmer for being patient with me as I fretted about this. I just found out that Napster leaves a client running in the background, and even though I had added firewall rules to block new connections to the server, the old 'established' connection was still up and running. I didn't realize that was the case, so that everytime I 'restarted' Napster the packets were getting through. In fact, what had happened was that the 'GUI' was being stopped/restarted, but the network portion was running the entire time. Once Guy walked me through and showed me that things were indeed working correct, we rebooted the box and my rules worked fine. Sorry for the false alarm! Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Blocking Napster (WAS: IPFW bug/incoming TCP connections being let in.)
Nate Williams wrote: I had blocked incoming TCP connections coming into my network using IPFW, and I noticed that my brother was able to establish a Napster connection, even though I had blocked it earlier. *sigh* Thanks to Guy Helmer for being patient with me as I fretted about this. I just found out that Napster leaves a client running in the background, and even though I had added firewall rules to block new connections to the server, the old 'established' connection was still up and running. This might be helpful to you and others. Since napster uses what ever ports it can find the best way is to block the servers. # Napster $fwcmd add deny tcp from any to 208.178.163.56/29 via tun0 $fwcmd add deny tcp from any to 208.178.175.128/29 via tun0 $fwcmd add deny tcp from any to 208.49.239.240/28 via tun0 $fwcmd add deny tcp from any to 208.49.228.0/24 via tun0 $fwcmd add deny tcp from any to 208.184.216.0/24 via tun0 Jim -- [EMAIL PROTECTED] http://www.FreeBSD.org The Power to Serve [EMAIL PROTECTED] http://www.TheHousleys.net - Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I'm convinced 'gcc' is meant to be pronounced 'ARRRRGGGHHH!'
Dag-Erling Smorgrav wrote: Will someone please inform the gcc developers of the last decade's advances in C standardization? Yes, Virginia, ISO C (it's not ISO C any more, and hasn't been since 1989) does support 'long long' and the 'll' format. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Sorry topost to everyone. I'll get my mailer fixed. But many times I have been comvinced that IEEE is indeed a primal scream! :) Have Fun, Sends Steve P.S. Back to lurking and hacking and amnsewering stacks of email. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Blocking Napster (WAS: IPFW bug/incoming TCP connections being let in.)
I had blocked incoming TCP connections coming into my network using IPFW, and I noticed that my brother was able to establish a Napster connection, even though I had blocked it earlier. *sigh* Thanks to Guy Helmer for being patient with me as I fretted about this. I just found out that Napster leaves a client running in the background, and even though I had added firewall rules to block new connections to the server, the old 'established' connection was still up and running. This might be helpful to you and others. Since napster uses what ever ports it can find the best way is to block the servers. # Napster $fwcmd add deny tcp from any to 208.178.163.56/29 via tun0 $fwcmd add deny tcp from any to 208.178.175.128/29 via tun0 $fwcmd add deny tcp from any to 208.49.239.240/28 via tun0 $fwcmd add deny tcp from any to 208.49.228.0/24 via tun0 $fwcmd add deny tcp from any to 208.184.216.0/24 via tun0 I had these rules in place, but it appears that there are new servers in place. I also had to to add $fwcmd add deny tcp from any to 64.124.41.0/24 via tun0 (I'm guessing it's a class C, I just had hit two addresses in that block, so I blocked the entire class C.) The above is the reason I was trying to do a 'port' block of the Napster servers, because trying to keep up with IP addresses is a real pain in the butt... Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
NFS/VM deadlock report and help request
I'm trying to locate a bug which causes a deadlock in VM subsystem
and would like to find some help here.
First of all, I'd describe the situation which has revealed the
problem.
We run a bunch of web servers providing free webpage service to our
customers. Back in July it was decided to upgrade the boxes due to security
issues with older kernels. Same time some other changes was done to the
internal network and some other stuff and now it's rather unclear whether
the upgrade is the cause, but thereafter we experience systematic httpd
hangups in uniterruptable waits ('D' status in ps output). Each hangup was
related to a webcam page with a image been updated each minute or so via
ftp (the way our customers update their pages).
While trying to find a solution we tested thttpd instead of apache
with one single box serving both HTTP and FTP. It resulted in even more
regular hangups occuring approximately each hour perhaps due to
single-process nature of thttpd. Just after another hangup the box was
taken out of service and preserved in that state so that I was able to dig
into the kernel and see what's going on.
Here is technical details I've got so far.
The kernel config I supply as an attachment. Kernel-mode stack
trace for the thttpd process looks like this:
==
IdlePTD 2928640
initial pcb at 1f1cf000
panic messages:
---
---
#0 mi_switch () at ../../kern/kern_synch.c:858
858 if (switchtime.tv_sec == 0)
#0 mi_switch () at ../../kern/kern_synch.c:858
#1 0xc0151881 in tsleep (ident=0xc05c38d0, priority=4,
wmesg=0xc0233171 "vmopar", timo=0) at ../../kern/kern_synch.c:467
#2 0xc01e40ff in vm_object_page_remove (object=0xdeb81c60, start=2, end=8,
clean_only=0) at ../../vm/vm_page.h:546
#3 0xc01e8189 in vnode_pager_setsize (vp=0xdeb8ec80, nsize=8192)
at ../../vm/vnode_pager.c:289
#4 0xc01a1cb7 in nfs_loadattrcache (vpp=0xdeb3ebec, mdp=0xdeb3ebf8,
dposp=0xdeb3ebfc, vaper=0x0) at ../../nfs/nfs_subs.c:1335
#5 0xc01a87e7 in nfs_readrpc (vp=0xdeb8ec80, uiop=0xdeb3ec60, cred=0xc4d49100)
at ../../nfs/nfs_vnops.c:1102
#6 0xc019b219 in nfs_getpages (ap=0xdeb3ec98) at ../../nfs/nfs_bio.c:153
#7 0xc01e8736 in vnode_pager_getpages (object=0xdeb81c60, m=0xdeb3ed2c,
count=2, reqpage=0) at vnode_if.h:1089
#8 0xc01dd606 in vm_fault (map=0xdc3e7e80, vaddr=712876032,
fault_type=1 '\001', fault_flags=0) at ../../vm/vm_pager.h:130
#9 0xc0209266 in trap_pfault (frame=0xdeb3eddc, usermode=0, eva=712876032)
at ../../i386/i386/trap.c:800
#10 0xc0208ecf in trap (frame={tf_fs = 134545424, tf_es = 16,
tf_ds = -599916528, tf_edi = -1054114628, tf_esi = 712876031,
tf_ebp = -558633400, tf_isp = -558633464, tf_ebx = 2048,
tf_edx = 712876867, tf_ecx = 209, tf_eax = -558641152, tf_trapno = 12,
tf_err = 0, tf_eip = -1071610959, tf_cs = 8, tf_eflags = 66054,
tf_esp = -558633252, tf_ss = -558633260}) at ../../i386/i386/trap.c:426
#11 0xc02083b1 in generic_copyin ()
#12 0xc0169c64 in sosend (so=0xdaea9780, addr=0x0, uio=0xdeb3eedc, top=0x0,
control=0x0, flags=0, p=0xdc3e45e0) at ../../kern/uipc_socket.c:567
#13 0xc015ef50 in soo_write (fp=0xc4eb0180, uio=0xdeb3eedc, cred=0xc4d49100,
flags=0, p=0xdc3e45e0) at ../../kern/sys_socket.c:78
#14 0xc015bc52 in dofilewrite (p=0xdc3e45e0, fp=0xc4eb0180, fd=76,
buf=0x2a7d9b43, nbyte=6797, offset=-1, flags=0) at ../../sys/file.h:159
#15 0xc015bb57 in write (p=0xdc3e45e0, uap=0xdeb3ef80)
at ../../kern/sys_generic.c:298
#16 0xc02098a5 in syscall2 (frame={tf_fs = -1078001617, tf_es = -558694353,
tf_ds = 47, tf_edi = 136698368, tf_esi = 68, tf_ebp = -1077938184,
tf_isp = -558633004, tf_ebx = 0, tf_edx = 0, tf_ecx = 134826912,
tf_eax = 4, tf_trapno = 0, tf_err = 2, tf_eip = 672115896, tf_cs = 31,
tf_eflags = 514, tf_esp = -1077938244, tf_ss = 47})
at ../../i386/i386/trap.c:1126
#17 0xc01fe4d6 in Xint0x80_syscall ()
#18 0x804a443 in ?? ()
#19 0x80499b5 in ?? ()
==
Further investigation has shown that the hangup happend while
trying to release a page which is most likely locked by NFS subsystem. The
page belongs to the image file I mentioned before.
Versions of the sources shown in the stack trace:
==
$FreeBSD: src/sys/kern/kern_synch.c,v 1.87.2.1 2000/05/16 06:58:12 dillon Exp $
$FreeBSD: src/sys/kern/kern_synch.c,v 1.87.2.1 2000/05/16 06:58:12 dillon Exp $
$FreeBSD: src/sys/kern/kern_synch.c,v 1.87.2.1 2000/05/16 06:58:12 dillon Exp $
$FreeBSD: src/sys/vm/vm_page.h,v 1.75 1999/12/29 04:55:10 peter Exp $
$FreeBSD: src/sys/vm/vnode_pager.c,v 1.116 1999/10/29 18:09:36 phk Exp $
$FreeBSD: src/sys/nfs/nfs_subs.c,v 1.90 2000/02/13 03:32:06 peter Exp $
$FreeBSD: src/sys/nfs/nfs_vnops.c,v 1.150 2000/01/05
Re: NFS/VM deadlock report and help request
On Fri, Oct 20, 2000 at 02:50:43PM +0200, Vadim Belman wrote:
The kernel config I supply as an attachment. Kernel-mode stack
trace for the thttpd process looks like this:
I think we've seen a similar problem and have a work around for it.
You could try the following patch, though it might take more fiddling
to get it right.
(The patch is by Ian Dowse, Matt Dillon had a quick look at it and said
it looked OK, we've been testing it for a bit here).
David.
Index: nfs/nfs.h
===
RCS file: /FreeBSD/FreeBSD-CVS/src/sys/nfs/nfs.h,v
retrieving revision 1.53
diff -u -r1.53 nfs.h
--- nfs/nfs.h 2000/01/13 20:18:25 1.53
+++ nfs/nfs.h 2000/10/20 16:13:49
@@ -616,7 +616,7 @@
struct ucred *, struct mbuf **, struct mbuf **,
caddr_t *));
intnfs_loadattrcache __P((struct vnode **, struct mbuf **, caddr_t *,
- struct vattr *));
+ struct vattr *, int));
intnfs_namei __P((struct nameidata *, fhandle_t *, int,
struct nfssvc_sock *, struct sockaddr *, struct mbuf **,
caddr_t *, struct vnode **, struct proc *, int, int));
Index: nfs/nfs_subs.c
===
RCS file: /FreeBSD/FreeBSD-CVS/src/sys/nfs/nfs_subs.c,v
retrieving revision 1.90
diff -u -r1.90 nfs_subs.c
--- nfs/nfs_subs.c 2000/02/13 03:32:06 1.90
+++ nfs/nfs_subs.c 2000/10/20 16:13:49
@@ -1203,11 +1203,12 @@
*copy the attributes to *vaper
*/
int
-nfs_loadattrcache(vpp, mdp, dposp, vaper)
+nfs_loadattrcache(vpp, mdp, dposp, vaper, dontshrink)
struct vnode **vpp;
struct mbuf **mdp;
caddr_t *dposp;
struct vattr *vaper;
+ int dontshrink;
{
register struct vnode *vp = *vpp;
register struct vattr *vap;
@@ -1322,9 +1323,18 @@
vap-va_gen = fxdr_unsigned(u_int32_t,fp-fa2_ctime.nfsv2_usec);
vap-va_filerev = 0;
}
+ np-n_attrstamp = time_second;
if (vap-va_size != np-n_size) {
if (vap-va_type == VREG) {
- if (np-n_flag NMODIFIED) {
+ if (dontshrink vap-va_size np-n_size) {
+ /*
+* We've been told not to shrink the file;
+* zero np-n_attrstamp to indicate that
+* the attributes are stale.
+*/
+ vap-va_size = np-n_size;
+ np-n_attrstamp = 0;
+ } else if (np-n_flag NMODIFIED) {
if (vap-va_size np-n_size)
vap-va_size = np-n_size;
else
@@ -1337,7 +1347,6 @@
np-n_size = vap-va_size;
}
}
- np-n_attrstamp = time_second;
if (vaper != NULL) {
bcopy((caddr_t)vap, (caddr_t)vaper, sizeof(*vap));
if (np-n_flag NCHG) {
Index: nfs/nfsm_subs.h
===
RCS file: /FreeBSD/FreeBSD-CVS/src/sys/nfs/nfsm_subs.h,v
retrieving revision 1.27
diff -u -r1.27 nfsm_subs.h
--- nfs/nfsm_subs.h 1999/08/28 00:50:02 1.27
+++ nfs/nfsm_subs.h 2000/10/20 16:13:49
@@ -212,7 +212,7 @@
#definenfsm_loadattr(v, a) \
do { \
struct vnode *ttvp = (v); \
- if ((t1 = nfs_loadattrcache(ttvp, md, dpos, (a))) != 0) { \
+ if ((t1 = nfs_loadattrcache(ttvp, md, dpos, (a), 0)) != 0) { \
error = t1; \
m_freem(mrep); \
goto nfsmout; \
@@ -226,7 +226,7 @@
nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
if (((f) = fxdr_unsigned(int, *tl)) != 0) { \
if ((t1 = nfs_loadattrcache(ttvp, md, dpos, \
- (struct vattr *)0)) != 0) { \
+ (struct vattr *)0, 1)) != 0) { \
error = t1; \
(f) = 0; \
m_freem(mrep); \
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: NFS/VM deadlock report and help request
:On Fri, Oct 20, 2000 at 02:50:43PM +0200, Vadim Belman wrote: : : The kernel config I supply as an attachment. Kernel-mode stack : trace for the thttpd process looks like this: : :I think we've seen a similar problem and have a work around for it. :You could try the following patch, though it might take more fiddling :to get it right. : :(The patch is by Ian Dowse, Matt Dillon had a quick look at it and said :it looked OK, we've been testing it for a bit here). : : David. Ah yes, that problem... if Ian's patch solves the problem for Vadim, I think you should go ahead and commit it. -Matt :Index: nfs/nfs.h :=== :RCS file: /FreeBSD/FreeBSD-CVS/src/sys/nfs/nfs.h,v :retrieving revision 1.53 :diff -u -r1.53 nfs.h :--- nfs/nfs.h 2000/01/13 20:18:25 1.53 :+++ nfs/nfs.h 2000/10/20 16:13:49 :@@ -616,7 +616,7 @@ :struct ucred *, struct mbuf **, struct mbuf **, :caddr_t *)); :... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NFS/VM deadlock report and help request
In message [EMAIL PROTECTED], Vadim Belman writes:
wmesg=0xc0233171 "vmopar", timo=0) at ../../kern/kern_synch.c:467
...
#8 0xc01dd606 in vm_fault (map=0xdc3e7e80, vaddr=712876032,
fault_type=1 '\001', fault_flags=0) at ../../vm/vm_pager.h:130
If anyone is interested, here are a few further details from my
mailbox. The patch David included appears to have solved this
particular problem for us, but there is another similar problem
lurking within the NFS/VM system.
Ian
The problem seems to originate with NFS's postop_attr information
that is returned with a read or write RPC. Within a vm_fault context,
the code cannot deal with vnode_pager_setsize() shrinking a vnode.
The workaround in the patch below stops the nfsm_postop_attr() macro
from ever shrinking a vnode. If the new size in the postop_attr
information is smaller, then it just sets the nfsnode n_attrstamp to 0
to stop the wrong size getting used in the future. This change only
affects postop_attr attributes; the nfsm_loadattr() macro works as
normal.
The change is implemented by adding a new argument to nfs_loadattrcache()
called 'dontshrink'. When this is non-zero, nfs_loadattrcache() will never
reduce the vnode/nfsnode size; instead it zeros n_attrstamp.
---
Hmm. We used this patch for a while - it stopped those particular vmopar
hangs, but another kind of deadlock has emerged (which happens with or
without the patch).
It seems that vinvalbuf() locks the vnode's v_interlock before calling
vm_object_page_remove(). vm_object_page_remove will then lock a page i.e.
vinvalbuf() [Lock v_interlock] -
vm_object_page_remove() [Lock page]
If another process concurrently vm_fault's on the same vnode then it
locks the page, and finishes with a vput(vp). vput() locks the
interlock, so it results in:
vm_fault() [Lock page] -
vput() [Lock v_interlock]
This is a simple lock-ordering deadlock. Since vm_fault can keep the
page locked for a considerable amount of time with NFS, this deadlock
can happen quite easily. I'm not sure what to suggest as a solution,
but keeping the v_interlock locked across a tsleep seems wrong... Any
ideas? Traces below.
#12 0xc02140f0 in atkbd_isa_intr (unit=0) at ../../i386/isa/atkbd_isa.c:84
#13 0xc020eceb in wait ()
#14 0xc01e22d3 in _unlock_things (fs=0xca6f0ef0, dealloc=0)
at ../../vm/vm_fault.c:148
#15 0xc01e2b73 in vm_fault (map=0xca6d2ac0, vaddr=134766592,
fault_type=1 '\001', fault_flags=0) at ../../vm/vm_fault.c:745
#16 0xc0210252 in trap_pfault (frame=0xca6f0fbc, usermode=1, eva=134769544)
at ../../i386/i386/trap.c:816
#17 0xc020fda2 in trap (frame={tf_es = 39, tf_ds = 39, tf_edi = -1077946880,
tf_esi = 1, tf_ebp = -1077947052, tf_isp = -898691100,
tf_ebx = -1077946872, tf_edx = 4, tf_ecx = -1077947772, tf_eax = 2,
tf_trapno = 12, tf_err = 4, tf_eip = 134769544, tf_cs = 31,
tf_eflags = 66050, tf_esp = -1077947172, tf_ss = 39})
at ../../i386/i386/trap.c:358
#18 0x8086b88 in ?? ()
(kgdb) proc 1042
(kgdb) bt
#0 mi_switch () at ../../kern/kern_synch.c:825
#1 0xc0150b4d in tsleep (ident=0xc0598534, priority=4,
wmesg=0xc024d22a "vmopar", timo=0) at ../../kern/kern_synch.c:443
#2 0xc01eaec6 in vm_page_sleep (m=0xc0598534, msg=0xc024d22a "vmopar",
busy=0xc0598563 "") at ../../vm/vm_page.c:1052
#3 0xc01e9aff in vm_object_page_remove (object=0xca6bac1c, start=0, end=0,
clean_only=1) at ../../vm/vm_object.c:1335
#4 0xc0172a6a in vinvalbuf (vp=0xca6bf700, flags=1, cred=0xc171ec80,
p=0xca6e5a40, slpflag=256, slptimeo=0) at ../../kern/vfs_subr.c:671
#5 0xc019541c in nfs_vinvalbuf (vp=0xca6bf700, flags=1, cred=0xc171ec80,
p=0xca6e5a40, intrflg=1) at ../../nfs/nfs_bio.c:978
#6 0xc01b6859 in nfs_open (ap=0xca6f3e2c) at ../../nfs/nfs_vnops.c:490
#7 0xc01796ae in vn_open (ndp=0xca6f3f00, fmode=1, cmode=1512)
at vnode_if.h:163
#8 0xc01760d9 in open (p=0xca6e5a40, uap=0xca6f3f94)
at ../../kern/vfs_syscalls.c:935
#9 0xc02108bf in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 134725618,
tf_esi = -1077946896, tf_ebp = -1077946944, tf_isp = -898678812,
tf_ebx = -1077946956, tf_edx = -1077946588, tf_ecx = 134893176,
tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip = 672042756, tf_cs = 31,
tf_eflags = 514, tf_esp = -1077949296, tf_ss = 39})
at ../../i386/i386/trap.c:1100
#10 0xc01ff11c in Xint0x80_syscall ()
#11 0x8049d39 in ?? ()
-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: burncd utility for atapi burners
I would like to communicate the proposed changes to the author but I did not find his address. Could somebody provide his email to me? [ ... ] This is going to be a problem in getting your changes accepted: +/*- + * t.h. changes copyright (c) 2000 Tomas Hruz + * All rights reserved. + */ Since that includes the right to integrate and distribute. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Boot off USB SanDisk?
SanDisk makes a IDE-like flash card one could plug into a $30 USB flashcard reader. Would FreeBSD have any idea how to boot off such a beast? Alternatively, anyone know of an ISA/PCI adapter with enough bios on it to boot off a similar flash? Thanks, --- David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot off USB SanDisk?
On Fri, 20 Oct 2000, David Miller wrote: Would FreeBSD have any idea how to boot off such a beast? Alternatively, anyone know of an ISA/PCI adapter with enough bios on it to boot off a similar flash? Put it in millenium disk-on-chip, 60 MB (soon) in the 32-pin DIP slot found on most mainboards nowadays (yes, they have moved from surface mount back to dip!) I'm booting to single-user in 3 seconds using these things. The IDE delays are high, even for Flash IDE, so going for the socket is a good thing. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Routing issue with cable modem
I tried replicating my windows routing table in freebsd. Only one entry didn't work... (guess) "route add default 10.17.56.xx" I'm cursed ! read below Goal -- to add cable modem as the default gateway to internet. Symptom -- "add net default: gateway 10.17.56.XXX: Network is unreachable" Problem -- I think modem gateway cannot be added because it's on a different subnet then my NICs. Attempted -- aliasing ed0 to modem subnet all 10.17.56 IPs seem to be occupied. It does sound like routing- A gateway, by definition, has to be on the same network as your NIC. I'm guessing your cable modem is in bridging mode? (vs routing mode) What would that mean in terms of my config changes ?? So is the cable modem in this computer, or is it some standalone device? The cable modem is an external device. It is connected to one of my two NICs. The other NIC has been connected to a small LAN for a while (which worked perfect with dialup PPP and NAT). And it is also connected to the TV cable and a phone line. The uplink is handled automatically by the modem. So it's presenting itself as some IP right? And you just have to use this IP as the default gateway for all your other machines- What is the subnet masking in place here? The modem works fine on my windows machine, and I looked up the configuration there (winipcfg). Windows sets 10.17.56.XXX as the default gateway (and DHCP server), and assigns 208.59.162.XXX (subnet 255.255.255.0) to me. DNS server is set to 207.172.3.9. Seems like should be no difficulty setting up unix in the same way... but unix does like 10.17.56.XXX as gateway (because supposedly network is unreachable). So that's the story... any suggestions? Ok, so the machine is being given a 208.59.162.xxx IP address (via DHCP), and a default gateway of 10.17.56.xx. Ok I think I know what's going on- Try manually adding the default route, but specify the interface that you want to use. It's something like: "route add default 10.17.56.xx netmask 255.255.255.0 interface ed0" "route add default 10.17.56.xx -netmask 255.255.255.0 -interface ed0" did not work, probably because 10.17.56.xx was specifying a gateway for the network 0.0.0.0 and ed0 was trying to be a gateway as well. I can however "route add default -interface ed0" which is actually the closest I've gotten to it working (modem dials out when I ping 10.17.56.1). "route add default 10.17.56.xx" would not work under any circumstances :( tells me "Network is unreachable". I just wonder how windows has no problem adding it as gateway. I think that because the machine doesnt have an interface on the 10.x.x.x network, it doesn't know how to get to the 10.x.x.0 network. I think you alternately could add a static route that looks like this: "route add 10.0.0.0 208.59.162.xx" When route to 10.0.0.0 is added, outgoing packets are corrupted (checked with ethereal). I.E. the header of the packet has 4 bytes inserted between the source and destination MACs. Those 4 bytes always seem to be part of the destination MAC itself. Following from another reply. defaultrouter="10.17.56.12" #-- fails with symptom previously described DHCP will normally configure the default route for you -- try setting this to NO. Tried setting to NO... DHCP doesn't seem to add a default route, so in my case it makes no difference really. Should it add default route? Normally, yes. You sort of need default route and netmask in order to make things work. This should happen with the stock dhclient.conf (which is empty). You could try to run dhclient by hand, something like: # killall dhclient # dhclient -dD ed0 Or whatever your interface is. Terminate it with Ctrl+C. You should get a bunch of files in /tmp, containing values received from the server. You may also get some interesting error messages. Tried "dhclient -d -D ed0" no files are written to /tmp dir. Do you think it could be a problem with my dhclient ? I tried using wide-dhcp client earlier, with even less success. Marko To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Routing issue with cable modem
On Fri, 20 Oct 2000, Marko Ruban wrote: I tried replicating my windows routing table in freebsd. Only one entry didn't work... (guess) "route add default 10.17.56.xx" I'm cursed ! My guess guess would be your DHCP client is not working right. Is it suppose to be using DHCP? Is it really something else like PPPoE? You see, the problem is not that the network is unreachable. It is that the default network is not DIRECTLY reachable. This is a violation of basic routing principles...although many devices work with that setup (Windows,Cisco,etc). FreeBSD does not allow you to add a default route to a network that is not directly connected. Why don't you dump your windows routing table `route -print` to the list and we could put together a routing table for you or see what is acutally going on. read below Goal -- to add cable modem as the default gateway to internet. Symptom -- "add net default: gateway 10.17.56.XXX: Network is unreachable" Problem -- I think modem gateway cannot be added because it's on a different subnet then my NICs. Attempted -- aliasing ed0 to modem subnet all 10.17.56 IPs seem to be occupied. It does sound like routing- A gateway, by definition, has to be on the same network as your NIC. I'm guessing your cable modem is in bridging mode? (vs routing mode) What would that mean in terms of my config changes ?? So is the cable modem in this computer, or is it some standalone device? The cable modem is an external device. It is connected to one of my two NICs. The other NIC has been connected to a small LAN for a while (which worked perfect with dialup PPP and NAT). And it is also connected to the TV cable and a phone line. The uplink is handled automatically by the modem. So it's presenting itself as some IP right? And you just have to use this IP as the default gateway for all your other machines- What is the subnet masking in place here? The modem works fine on my windows machine, and I looked up the configuration there (winipcfg). Windows sets 10.17.56.XXX as the default gateway (and DHCP server), and assigns 208.59.162.XXX (subnet 255.255.255.0) to me. DNS server is set to 207.172.3.9. Seems like should be no difficulty setting up unix in the same way... but unix does like 10.17.56.XXX as gateway (because supposedly network is unreachable). So that's the story... any suggestions? Ok, so the machine is being given a 208.59.162.xxx IP address (via DHCP), and a default gateway of 10.17.56.xx. Ok I think I know what's going on- Try manually adding the default route, but specify the interface that you want to use. It's something like: "route add default 10.17.56.xx netmask 255.255.255.0 interface ed0" "route add default 10.17.56.xx -netmask 255.255.255.0 -interface ed0" did not work, probably because 10.17.56.xx was specifying a gateway for the network 0.0.0.0 and ed0 was trying to be a gateway as well. I can however "route add default -interface ed0" which is actually the closest I've gotten to it working (modem dials out when I ping 10.17.56.1). "route add default 10.17.56.xx" would not work under any circumstances :( tells me "Network is unreachable". I just wonder how windows has no problem adding it as gateway. I think that because the machine doesnt have an interface on the 10.x.x.x network, it doesn't know how to get to the 10.x.x.0 network. I think you alternately could add a static route that looks like this: "route add 10.0.0.0 208.59.162.xx" When route to 10.0.0.0 is added, outgoing packets are corrupted (checked with ethereal). I.E. the header of the packet has 4 bytes inserted between the source and destination MACs. Those 4 bytes always seem to be part of the destination MAC itself. Following from another reply. defaultrouter="10.17.56.12" #-- fails with symptom previously described DHCP will normally configure the default route for you -- try setting this to NO. Tried setting to NO... DHCP doesn't seem to add a default route, so in my case it makes no difference really. Should it add default route? Normally, yes. You sort of need default route and netmask in order to make things work. This should happen with the stock dhclient.conf (which is empty). You could try to run dhclient by hand, something like: # killall dhclient # dhclient -dD ed0 Or whatever your interface is. Terminate it with Ctrl+C. You should get a bunch of files in /tmp, containing values received from the server. You may also get some interesting error messages. Tried "dhclient -d -D ed0" no files are written to /tmp dir. Do you think it could be a problem with my dhclient ? I tried using wide-dhcp client earlier, with
Re: Routing issue with cable modem
Nick Rogness wrote:
On Fri, 20 Oct 2000, Marko Ruban wrote:
> I tried replicating my windows routing table in freebsd.
> Only one entry didn't work... (guess)
> "route add default 10.17.56.xx"
>
> I'm cursed !
My guess guess would be your
DHCP client is not working right.
Is it suppose to be using
DHCP? Is it really something else like
PPPoE?
It definitely uses DHCP, because I update the setup with "winipcfg" whenever
I switch the modem over to windows machine.
Also ethereal (for windows) shows DHCP packets being exchanged.
You see,
the problem is not that the network is unreachable. It
is that the default network
is not DIRECTLY reachable. This is a
violation of basic routing
principles...although many devices work
with that setup (Windows,Cisco,etc).
FreeBSD does not allow you
to add a default route to
a network that is not directly
connected.
If windows can do it, freebsd probably can too, even if it takes a custom
program ;)
Why don't
you dump your windows routing table `route -print` to
the list and we could put
together a routing table for you or see
what is acutally going on.
NOTE: table below best viewed in proportional font
('route print' and 'netstat -r' seem to yield identical results)
C:\WINDOWS>netstat -r
Route Table
Active Routes:
Network Address
Netmask Gateway Address
Interface Metric
0.0.0.0
0.0.0.0 10.17.56.12 208.59.162.242
1
127.0.0.0
255.0.0.0 127.0.0.1
127.0.0.1 1
208.59.162.0 255.255.255.0
208.59.162.242 208.59.162.242
1
208.59.162.242 255.255.255.255
127.0.0.1 127.0.0.1
1
208.59.162.255 255.255.255.255 208.59.162.242
208.59.162.242 1
224.0.0.0
224.0.0.0 208.59.162.242 208.59.162.242
1
255.255.255.255 255.255.255.255 208.59.162.242
208.59.162.242 1
I also edited (a copy of) the dhclient-script to dump output of commands
to /tmp instead of /dev/null maybe I'll see something interesting there.
*** old discussion follows
> > > > > Goal -- to add cable modem as the default
gateway to internet.
> > > > > Symptom -- "add net default: gateway 10.17.56.XXX: Network
is
> > > > > unreachable"
> > > > > Problem -- I think modem gateway cannot be added because
it's on a
> > > > > different subnet then my NICs.
> > > > > Attempted -- aliasing ed0 to modem subnet all 10.17.56
IPs seem to
> > > > > be occupied.
> > > >
> > > > It does sound like routing-
> > > > A gateway, by definition, has to be on the same network as
your NIC.
> > > > I'm guessing your cable modem is in bridging mode? (vs routing
mode)
> > >
> > > What would that mean in terms of my config changes ??
>
> > So is the cable modem in this computer, or is it some standalone
device?
>
> The cable modem is an external device. It is connected to one
of my two NICs.
> The other NIC has been connected to a small LAN for a while (which
worked
> perfect with dialup PPP and NAT). And it is also connected
to the TV cable and
> a phone line. The uplink is handled automatically by the modem.
>
> > > > So it's presenting itself as some IP right?
> > > > And you just have to use this IP as the default gateway for
all your
> > other
> > > > machines-
> > >
> > > > What is the subnet masking in place here?
> > >
> > > The modem works fine on my windows machine, and I looked up the
> > configuration
> > > there (winipcfg).
> > > Windows sets 10.17.56.XXX as the default gateway (and DHCP server),
and
> > assigns
> > > 208.59.162.XXX (subnet 255.255.255.0) to me. DNS server
is set to
> > 207.172.3.9.
> > >
> > > Seems like should be no difficulty setting up unix in the same
way... but
> > unix
> > > does like 10.17.56.XXX as gateway (because supposedly network
is
> > unreachable).
> > >
> > > So that's the story... any suggestions?
> >
> > Ok, so the machine is being given a 208.59.162.xxx IP address (via
DHCP),
> > and a default gateway of 10.17.56.xx.
> >
> > Ok I think I know what's going on-
> >
> > Try manually adding the default route, but specify the interface
that you
> > want to use.
> > It's something like:
> >
> > "route add default 10.17.56.xx netmask 255.255.255.0 interface
ed0"
>
> "route add default 10.17.56.xx -netmask 255.255.255.0 -interface
ed0" did not
> work, probably because 10.17.56.xx was specifying a gateway for the
network
> 0.0.0.0 and ed0 was trying to be a gateway as well. I can however
"route add
> default -interface ed0" which is actually the closest I've gotten
to it working
> (modem dials out when I ping 10.17.56.1).
>
> "route add default 10.17.56.xx" would not work under any circumstances
:(
> tells me "Network is unreachable". I just wonder how windows
has no problem
> adding it as gateway.
>
> > I think that because the machine doesnt have an interface on the
10.x.x.x
> > network, it doesn't know how to get to the 10.x.x.0 network.
> >
> > I think you alternately could add a static route that looks like
this:
> >
> > "route add 10.0.0.0 208.59.162.xx"
>
> When route to 10.0.0.0 is added, outgoing packets are corrupted (checked
with
> ethereal). I.E. the header of the packet has 4
Re: Routing issue with cable modem
On Fri, 20 Oct 2000, Nick Rogness wrote: Made an error in my previous statement, clarification below: On Fri, 20 Oct 2000, Marko Ruban wrote: I tried replicating my windows routing table in freebsd. Only one entry didn't work... (guess) "route add default 10.17.56.xx" I'm cursed ! My guess guess would be your DHCP client is not working right. Is it suppose to be using DHCP? Is it really something else like PPPoE? You see, the problem is not that the network is unreachable. It is that the default network is not DIRECTLY reachable. This is a violation of basic routing principles...although many devices work This is not neccessarily true. There are some instances where this is perfectly legal and are out-of-scope for this mail. However, they are usually handled by dynamic routing protocols and/or other equipment/software interaction. This argument has come up before on this list and the concept has went back and forth on why's and why not's. with that setup (Windows,Cisco,etc). FreeBSD does not allow you to add a default route to a network that is not directly connected. Why don't you dump your windows routing table `route -print` to the list and we could put together a routing table for you or see what is acutally going on. Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Routing issue with cable modem
New issue seems to be at hand... I set the alias for the interface to be the gateway IP (10.17.56.12), and then I was able to add that as my default gateway. Not sure why aliasing wouldn't work with 10.17.56.11 or some other IP in that subnet. I tried to ping the DNS server after that, and watched hundreds of corrupt packets get sent out with no replies. So my new question is, which part of the system actually builds the packets ? Any way to debug or log that process ? Here's an example taken from ethereal output (view with proportional font) - Frame 6 (102 on wire, 102 captured) Arrival Time: Oct 20, 2000 16:42:38.2715 Time delta from previous packet: 0.71 seconds Frame Number: 6 Packet Length: 102 bytes Capture Length: 102 bytes Ethernet II Destination: 02:00:00:00:52:54 (02:00:00:00:52:54) Source: 05:f4:21:3f:52:54 (05:f4:21:3f:52:54) Type: Unknown (0x05f4) Data (88 bytes) 0 0200 5254 05f4 213f 5254 05f4 213f RT..!?RT..!? 10 0800 4500 0054 13fa fa01 97dc 0a11 ..E..T.. 20 380c cfac 0309 0800 c1f0 6101 3eae 8.a 30 f039 b722 0400 0809 0a0b 0c0d 0e0f 1011 .9." 40 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 .. ! 50 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 "#$%'()*+,-./01 60 3233 3435 3637234567 - Why I think this packet is malformed. First of all, protocol type Unknown (0x05f4) looks definitely bad. Secondly, protocol type looks like part of my NICs MAC address (52:54:05:f4:21:3f according to ifconfig, which translates into hex: 0x5254 05f4 213f). Thirdly, source address decoded by ethereal (and probably by any other packet processor) is wrong (first two bytes are carried over to the other side). Now, keeping all that in mind, lets do a pattern match on the REAL MAC address in hex dump of the packet. HEY, the source address actually starts four bytes later than it should, thus shifting the TRUE protocol type (0x0800 = IP) as well. First six bytes are the destination MAC, then come the EVIL 4 bytes, followed by 6 bytes of source MAC. I don't know what's going on, but looks pretty bad, yet simple on the hex level :) Any ideas ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Routing issue with cable modem
That was some really really nasty HTML there, I think you might want to send that again as plaintext. -- E-Mail: Joel Bjork [EMAIL PROTECTED] Date: 20-Oct-00 Time: 23:41:10 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Routing issue with cable modem
Joel said HTML was badly formatted, so I'm resubmitting in plain text. Thanks :) New issue seems to be at hand... I set the alias for the interface to be the gateway IP (10.17.56.12), and then I was able to add that as my default gateway. Not sure why aliasing wouldn't work with 10.17.56.11 or some other IP in that subnet. I tried to ping the DNS server after that, and watched hundreds of corrupt packets get sent out with no replies. So my new question is, which part of the system actually builds the packets ? Any way to debug or log that process ? Here's an example taken from ethereal output (view with proportional font) - Frame 6 (102 on wire, 102 captured) Arrival Time: Oct 20, 2000 16:42:38.2715 Time delta from previous packet: 0.71 seconds Frame Number: 6 Packet Length: 102 bytes Capture Length: 102 bytes Ethernet II Destination: 02:00:00:00:52:54 (02:00:00:00:52:54) Source: 05:f4:21:3f:52:54 (05:f4:21:3f:52:54) Type: Unknown (0x05f4) Data (88 bytes) 0 0200 5254 05f4 213f 5254 05f4 213f RT..!?RT..!? 10 0800 4500 0054 13fa fa01 97dc 0a11 ..E..T.. 20 380c cfac 0309 0800 c1f0 6101 3eae 8.a 30 f039 b722 0400 0809 0a0b 0c0d 0e0f 1011 .9." 40 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 .. ! 50 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 "#$%'()*+,-./01 60 3233 3435 3637234567 - Why I think this packet is malformed. First of all, protocol type Unknown (0x05f4) looks definitely bad. Secondly, protocol type looks like part of my NICs MAC address (52:54:05:f4:21:3f according to ifconfig, which translates into hex: 0x5254 05f4 213f). Thirdly, source address decoded by ethereal (and probably by any other packet processor) is wrong (first two bytes are carried over to the other side). Now, keeping all that in mind, lets do a pattern match on the REAL MAC address in hex dump of the packet. HEY, the source address actually starts four bytes later than it should, thus shifting the TRUE protocol type (0x0800 = IP) as well. First six bytes are the destination MAC, then come the EVIL 4 bytes, followed by 6 bytes of source MAC. I don't know what's going on, but looks pretty bad, yet simple on the hex level :) Any ideas ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Ski Bum News Subscription
I am very sorry to bother you but our mailing list at the Ski Bum News was destroyed. If you were receiving a FREE SUBSCRIPTION to http://www.SkiBumNews.com or WOULD like to please respond with Subscription in the subject box. If you were not receiving a subscription or do NOT want one do NOTHING, we will not contact you again regarding this matter. Please let me apologize again for bothering you, there was nothing else I could think of to do. Sincerely, The Editor To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Routing issue with cable modem
Marko Ruban wrote: I tried replicating my windows routing table in freebsd. Only one entry didn't work... (guess) "route add default 10.17.56.xx" I'm cursed ! read below Goal -- to add cable modem as the default gateway to internet. Symptom -- "add net default: gateway 10.17.56.XXX: Network is unreachable" Problem -- I think modem gateway cannot be added because it's on a different subnet then my NICs. Attempted -- aliasing ed0 to modem subnet all 10.17.56 IPs seem to be occupied. It does sound like routing- A gateway, by definition, has to be on the same network as your NIC. I'm guessing your cable modem is in bridging mode? (vs routing mode) What would that mean in terms of my config changes ?? So is the cable modem in this computer, or is it some standalone device? The cable modem is an external device. It is connected to one of my two NICs. The other NIC has been connected to a small LAN for a while (which worked perfect with dialup PPP and NAT). And it is also connected to the TV cable and a phone line. The uplink is handled automatically by the modem. So it's presenting itself as some IP right? And you just have to use this IP as the default gateway for all your other machines- What is the subnet masking in place here? The modem works fine on my windows machine, and I looked up the configuration there (winipcfg). Windows sets 10.17.56.XXX as the default gateway (and DHCP server), and assigns 208.59.162.XXX (subnet 255.255.255.0) to me. DNS server is set to 207.172.3.9. Seems like should be no difficulty setting up unix in the same way... but unix does like 10.17.56.XXX as gateway (because supposedly network is unreachable). So that's the story... any suggestions? Ok, so the machine is being given a 208.59.162.xxx IP address (via DHCP), and a default gateway of 10.17.56.xx. Ok I think I know what's going on- Try manually adding the default route, but specify the interface that you want to use. It's something like: "route add default 10.17.56.xx netmask 255.255.255.0 interface ed0" "route add default 10.17.56.xx -netmask 255.255.255.0 -interface ed0" did not work, probably because 10.17.56.xx was specifying a gateway for the network 0.0.0.0 and ed0 was trying to be a gateway as well. I can however "route add default -interface ed0" which is actually the closest I've gotten to it working (modem dials out when I ping 10.17.56.1). "route add default 10.17.56.xx" would not work under any circumstances :( tells me "Network is unreachable". I just wonder how windows has no problem adding it as gateway. I think that because the machine doesnt have an interface on the 10.x.x.x network, it doesn't know how to get to the 10.x.x.0 network. I think you alternately could add a static route that looks like this: "route add 10.0.0.0 208.59.162.xx" When route to 10.0.0.0 is added, outgoing packets are corrupted (checked with ethereal). I.E. the header of the packet has 4 bytes inserted between the source and destination MACs. Those 4 bytes always seem to be part of the destination MAC itself. Following from another reply. defaultrouter="10.17.56.12" #-- fails with symptom previously described DHCP will normally configure the default route for you -- try setting this to NO. Tried setting to NO... DHCP doesn't seem to add a default route, so in my case it makes no difference really. Should it add default route? Normally, yes. You sort of need default route and netmask in order to make things work. This should happen with the stock dhclient.conf (which is empty). You could try to run dhclient by hand, something like: # killall dhclient # dhclient -dD ed0 Or whatever your interface is. Terminate it with Ctrl+C. You should get a bunch of files in /tmp, containing values received from the server. You may also get some interesting error messages. Tried "dhclient -d -D ed0" no files are written to /tmp dir. Do you think it could be a problem with my dhclient ? I tried using wide-dhcp client earlier, with even less success. Marko To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message I could never manually config my cable modem for @home; it works if you let DHCP config it. [ifconfig_ep0="DHCP" - in rc.conf] -- P. Murphy Home: Lat 43.5584 Long -79.6502 Work: Lat 43.4277 Long -79.7077 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Routing issue with cable modem
Hello, Have you perhaps updated to a new kernel since you installed ethereal? I seem to recall seing similiar situations to this when some data structures changed sizes. Is "/usr/sbin/tcpdump -e" showing this same MAC address corruption you describe? If not, I would recommend rebuilding ethereal. TOny. On Fri, 20 Oct 2000, Marko Ruban wrote: New issue seems to be at hand... I set the alias for the interface to be the gateway IP (10.17.56.12), and then I was able to add that as my default gateway. Not sure why aliasing wouldn't work with 10.17.56.11 or some other IP in that subnet. I tried to ping the DNS server after that, and watched hundreds of corrupt packets get sent out with no replies. So my new question is, which part of the system actually builds the packets ? Any way to debug or log that process ? Here's an example taken from ethereal output (view with proportional font) - Frame 6 (102 on wire, 102 captured) Arrival Time: Oct 20, 2000 16:42:38.2715 Time delta from previous packet: 0.71 seconds Frame Number: 6 Packet Length: 102 bytes Capture Length: 102 bytes Ethernet II Destination: 02:00:00:00:52:54 (02:00:00:00:52:54) Source: 05:f4:21:3f:52:54 (05:f4:21:3f:52:54) Type: Unknown (0x05f4) Data (88 bytes) 0 0200 5254 05f4 213f 5254 05f4 213f RT..!?RT..!? 10 0800 4500 0054 13fa fa01 97dc 0a11 ..E..T.. 20 380c cfac 0309 0800 c1f0 6101 3eae 8.a 30 f039 b722 0400 0809 0a0b 0c0d 0e0f 1011 .9." 40 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 .. ! 50 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 "#$%'()*+,-./01 60 3233 3435 3637234567 - Why I think this packet is malformed. First of all, protocol type Unknown (0x05f4) looks definitely bad. Secondly, protocol type looks like part of my NICs MAC address (52:54:05:f4:21:3f according to ifconfig, which translates into hex: 0x5254 05f4 213f). Thirdly, source address decoded by ethereal (and probably by any other packet processor) is wrong (first two bytes are carried over to the other side). Now, keeping all that in mind, lets do a pattern match on the REAL MAC address in hex dump of the packet. HEY, the source address actually starts four bytes later than it should, thus shifting the TRUE protocol type (0x0800 = IP) as well. First six bytes are the destination MAC, then come the EVIL 4 bytes, followed by 6 bytes of source MAC. I don't know what's going on, but looks pretty bad, yet simple on the hex level :) Any ideas ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Assembly Journal article
I just wanted to let you all know that I have submitted my second article on FreeBSD assembly language programming to Assembly Language Journal. (The first one was published in Issue 8: http://asmjournal.freeservers.com/ ) If you want to read it before it is published, see http://www.whizkidtech.net/args.txt . If you want the code from the article, download http://www.whizkidtech.net/args.asm and assemble it with NASM: nasm -f elf args.asm ld -o args args.o strip args Cheers, Adam -- Don't send me spam, I'm a vegetarian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
