ng_pptpgre + netmask_change results to lock
Hello everybody, I just managed to lock my box and I want to report it in case it's known(or it helps in some way). It is a 6.2-STABLE from March 13. The procedure that triggers the lock is simple: 1) Create a pptp tunnel. 2) Set is as your default gateway. 3) Play a bit with the netmask of the physical inteface. In my case doing a few times: ifconfig fxp0 192.168.1.71/16 ifconfig fxp0 192.168.1.71/24 locks the box. It's the GENERIC kernel along with: nik:0:~$ kldstat Id Refs AddressSize Name 1 16 0xc040 70b690 kernel 21 0xc0b0c000 5fa0 snd_ich.ko 32 0xc0b12000 22c48sound.ko 41 0xc0b35000 598bcacpi.ko 51 0xc3863000 2000 green_saver.ko 61 0xc38b7000 4000 ng_socket.ko 78 0xc38bb000 a000 netgraph.ko 81 0xc38cd000 3000 ng_iface.ko 91 0xc38d8000 6000 ng_ppp.ko 101 0xc38f 4000 ng_vjc.ko 111 0xc38f6000 4000 ng_bpf.ko 121 0xc38fd000 2000 ng_tcpmss.ko 131 0xc38ff000 4000 ng_pptpgre.ko 141 0xc3903000 4000 ng_ksocket.ko Anybody with a more recent -STABLE can confirm that the problem is still there? or not? Any thoughts before updating my /usr/src? Thanks in advance, Nikos ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is em endian-clean?
Yes, Linux is tested on big endian, however FreeBSD testing is limited. I would expect the shared code to be ok but the core code is tested on little endian only. Do you have some notion of where the problem is? I'm pretty busy with another issue right at the moment. Jack On 5/21/07, Kip Macy <[EMAIL PROTECTED]> wrote: Hi Jack - I believe I've fixed the sun4v breakage caused by the interrupt filter changes but it appears that em still isn't working. Does Intel test at all on big endian hardware? If not, what do you do to avoid breaking e1000 on Linux? Thanks. -Kip ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Detecting LINK_UP / LINK_DOWN events
> -Original Message-
> From: Tom Judge [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 22, 2007 12:01 AM
> To: Sastry Tumuluri
> Cc: freebsd-net@freebsd.org
> Subject: Re: Detecting LINK_UP / LINK_DOWN events
>
> Sastry Tumuluri wrote:
> > Friends,
> >
> > I am trying to catch and do some extra processing on LINK_UP and
> > LINK_DOWN events for my net interfaces (e.g., notify my
> admin, log the event, ...).
> > Tried this on both FreeBSD 6.1 and on FreeBSD 6.2.
> >
> > I tried using the devd.conf file with the following code (shows
> > LINK_DOWN; wrote similar stuff for LINK_UP):
> >
> > notify 10 {
> >match "type""LINK_DOWN";
> >action "logger -s alert: Caught LINK_DOWN on dev: $device-name
> > subsys: $subsystem";
> > };
> >
> > Didn't work. I tried the above with both strict match conditions
> > (using vendor, device and class matches) as well as very
> general (like the above).
> > Didn't work.
> > I ran killed devd and ran it in the foreground with "devd
> -dD". Then I
> > logged into a different pty and used
> > ifconfig lnc0 down #(lnc0 is my ethernet device).
> > devd doesn't even seem to catch the event (no output at all
> - both on
> > screen and in syslog).
> >
> >
> > On the other hand, "nomatch" and "attach" messages do seem to get
> > through (I wrote similar stuff for nomatch & attach, and they are
> > showing up at bootup and in syslog).
> > What could I be doing wrong?
> >
>
> Have you had a look at net/ifstated in ports?
>
> Tom
>
Thanks, Tom! Though I had not heard of ifstated before this, it looks
interesting. I've managed to quickly get the latest port and install it
without any hassles - but am still a bit short on documentation - esp., how
the .conf file works, and how to make ifstated work for me. I haven't used
carp so far; and am not sure whether I need to, if all I want is a simple
"notification / logging". Any suggestions?
On the other hand, I am still curious why devd didn't work in the first
place. Is it a "futuristic" feature already advertised (in the devd.conf
file, there are examples of LINK_UP/LINK_DOWN that make it look like it
should work)? Or a case for better documentation?
Regards,
==Sas3==
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 5/21/2007
2:01 PM
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Detecting LINK_UP / LINK_DOWN events
On Tuesday 22 May 2007 12:19, Sastry Tumuluri wrote:
> > -Original Message-
> > From: Tom Judge [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, May 22, 2007 12:01 AM
> > To: Sastry Tumuluri
> > Cc: freebsd-net@freebsd.org
> > Subject: Re: Detecting LINK_UP / LINK_DOWN events
> >
> > Sastry Tumuluri wrote:
> > > Friends,
> > >
> > > I am trying to catch and do some extra processing on LINK_UP and
> > > LINK_DOWN events for my net interfaces (e.g., notify my
> >
> > admin, log the event, ...).
> >
> > > Tried this on both FreeBSD 6.1 and on FreeBSD 6.2.
> > >
> > > I tried using the devd.conf file with the following code (shows
> > > LINK_DOWN; wrote similar stuff for LINK_UP):
> > >
> > > notify 10 {
> > >match "type""LINK_DOWN";
> > >action "logger -s alert: Caught LINK_DOWN on dev: $device-name
> > > subsys: $subsystem";
> > > };
> > >
> > > Didn't work. I tried the above with both strict match conditions
> > > (using vendor, device and class matches) as well as very
> >
> > general (like the above).
> >
> > > Didn't work.
> > > I ran killed devd and ran it in the foreground with "devd
> >
> > -dD". Then I
> >
> > > logged into a different pty and used
> > > ifconfig lnc0 down #(lnc0 is my ethernet device).
> > > devd doesn't even seem to catch the event (no output at all
> >
> > - both on
> >
> > > screen and in syslog).
> > >
> > >
> > > On the other hand, "nomatch" and "attach" messages do seem to get
> > > through (I wrote similar stuff for nomatch & attach, and they are
> > > showing up at bootup and in syslog).
> > > What could I be doing wrong?
> >
> > Have you had a look at net/ifstated in ports?
> >
> > Tom
>
> Thanks, Tom! Though I had not heard of ifstated before this, it looks
> interesting. I've managed to quickly get the latest port and install it
> without any hassles - but am still a bit short on documentation - esp.,
> how the .conf file works, and how to make ifstated work for me. I
> haven't used carp so far; and am not sure whether I need to, if all I
> want is a simple "notification / logging". Any suggestions?
>
> On the other hand, I am still curious why devd didn't work in the first
> place. Is it a "futuristic" feature already advertised (in the devd.conf
> file, there are examples of LINK_UP/LINK_DOWN that make it look like it
> should work)? Or a case for better documentation?
Did you try pulling the plug?
LINK events refer to the change of link status, not
the "UP" status. That is the "status: active" line .
nik:0:~$ ifconfig fxp0
fxp0: flags=8843 mtu 1500
options=8
inet 192.168.1.71 netmask 0xff00 broadcast 192.168.1.255
ether 00:0c:f1:b9:38:50
media: Ethernet autoselect (100baseTX )
status: active
HTH, Nikos
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Detecting LINK_UP / LINK_DOWN events
> -Original Message-
> From: Nikos Vassiliadis [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 22, 2007 2:58 PM
> On Tuesday 22 May 2007 12:19, Sastry Tumuluri wrote:
> > > -Original Message-
> > > From: Tom Judge [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, May 22, 2007 12:01 AM
> > > Sastry Tumuluri wrote:
> > > > Friends,
> > > >
> > > > I am trying to catch and do some extra processing on
> LINK_UP and
> > > > LINK_DOWN events for my net interfaces (e.g., notify my
> > >
> > > admin, log the event, ...).
> > >
> > > > Tried this on both FreeBSD 6.1 and on FreeBSD 6.2.
> > > >
> > > > I tried using the devd.conf file with the following code (shows
> > > > LINK_DOWN; wrote similar stuff for LINK_UP):
> > > >
> > > > notify 10 {
> > > >match "type""LINK_DOWN";
> > > >action "logger -s alert: Caught LINK_DOWN on dev:
> $device-name
> > > > subsys: $subsystem";
> > > > };
> > > >
> > > > Didn't work. I tried the above with both strict match
> conditions
> > > > (using vendor, device and class matches) as well as very
> > >
> > > general (like the above).
> > >
> > > > Didn't work.
> > > > I ran killed devd and ran it in the foreground with "devd
> > >
> > > -dD". Then I
> > >
> > > > logged into a different pty and used
> > > > ifconfig lnc0 down #(lnc0 is my ethernet device).
> > > > devd doesn't even seem to catch the event (no output at all
> > >
> > > - both on
> > >
> > > > screen and in syslog).
> > > >
> > > >
> > > > On the other hand, "nomatch" and "attach" messages do
> seem to get
> > > > through (I wrote similar stuff for nomatch & attach,
> and they are
> > > > showing up at bootup and in syslog).
> > > > What could I be doing wrong?
> > >
> > > Have you had a look at net/ifstated in ports?
> > >
> > > Tom
> >
> > Thanks, Tom! Though I had not heard of ifstated before
> this, it looks
> > interesting. I've managed to quickly get the latest port
> and install
> > it without any hassles - but am still a bit short on
> documentation -
> > esp., how the .conf file works, and how to make ifstated
> work for me.
> > I haven't used carp so far; and am not sure whether I need
> to, if all
> > I want is a simple "notification / logging". Any suggestions?
> >
> > On the other hand, I am still curious why devd didn't work in the
> > first place. Is it a "futuristic" feature already
> advertised (in the
> > devd.conf file, there are examples of LINK_UP/LINK_DOWN
> that make it
> > look like it should work)? Or a case for better documentation?
>
> Did you try pulling the plug?
> LINK events refer to the change of link status, not the "UP"
> status. That is the "status: active" line .
>
> nik:0:~$ ifconfig fxp0
> fxp0: flags=8843 mtu 1500
> options=8
> inet 192.168.1.71 netmask 0xff00 broadcast 192.168.1.255
> ether 00:0c:f1:b9:38:50
> media: Ethernet autoselect (100baseTX )
> status: active
>
> HTH, Nikos
>
That solved one mystery, Nikos! Yes, the LINK_UP/LINK_DOWN do seem to refer
to the status of the physical media (plugged in or out). While at it, I also
found that
ifconfig em0 down (not pulling out the media, just the command)
does not send any status message (perhaps a driver feature? Not
sure), but
ifconfig em0 up
does send a LINK_DOWN first and then a LINK_UP. This doesn't seem to
have any relation to whether or not the IP address is there or
-aliased.
It still leaves me with my original problem that of "detecting changes to
the
interfaces and logging them / sending alerts". This needs to work for me for
any
Interface: real / psuedo (is that word for ppp0/tun0/etc...?) and any type
of
change: e.g. ip-addr change thru dhcp/pppoe/static etc.. :-( So I guess I'll
keep plugging away at ifstated (carp or no-carp), then!! :-)
Regards,
==Sas3==
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 5/21/2007
2:01 PM
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
walking (and cleaning) the routing table on mask change?
Hello, colleagues, what do you think about cleaning the routing table on mask change? I think it should be done. Currently we are cleaning the routing table only on SIOCDIFADDR operation, because it removes prefix from an interface. However, SIOCAIFADDR also may delete (actually replace) a prefix on interface, in the case of mask change. For example: [EMAIL PROTECTED]:~:|>ifconfig em0 10.0.0.195/24 [EMAIL PROTECTED]:~:|>route add 10.0.1.0/24 10.0.0.1 add net 10.0.1.0: gateway 10.0.0.1 [EMAIL PROTECTED]:~:|>netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire 10.0.0.0/24link#2 UC 00em0 10.0.0.1 link#2 UHLW20em0 10.0.1.0/2410.0.0.1 UGS 00em0 127.0.0.1 127.0.0.1 UH 0 26lo0 [EMAIL PROTECTED]:~:|>ifconfig em0 netmask 255.255.255.128 [EMAIL PROTECTED]:~:|>netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire 10.0.0.128/25 link#2 UC 00em0 10.0.1.0/2410.0.0.1 UGS 00em0 ^^ --- shouldn't it be deleted? 127.0.0.1 127.0.0.1 UH 0 26lo0 [EMAIL PROTECTED]:~:|> 10.0.0.1 isn't reachable now. Currently, we have a workaroung in rt_check() (rev. 1.117) that prevents us from panicing. However, the invalid route still remains in the table. I suggest to make the following on the mask change path: rt_tables[AF_INET]->rnh_walktree(xxx_maskchange), where the xxx_maskchange() deletes all routes, which used to be reachable via the old mask and are no longer reachable. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is em endian-clean?
On 5/22/07, Jack Vogel <[EMAIL PROTECTED]> wrote: Yes, Linux is tested on big endian, however FreeBSD testing is limited. I would expect the shared code to be ok but the core code is tested on little endian only. Do you have some notion of where the problem is? I'm pretty busy with another issue right at the moment. Jack I am setting up an older MAC our test group had, adding at least basic traffic passing test to our test cycle. Regards, Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: walking (and cleaning) the routing table on mask change?
> what do you think about cleaning the routing table on mask change? I think it would be far easier and more correct to not allow just the mask change (which is never really needed). $ ifconfig tap0 10.1.1.0/24 $ netstat -nr | grep tap0 10.1.1.0/24link#6 UC 00 tap0 $ ifconfig tap0 10.1.1.0/26 $ netstat -nr | grep tap0 10.1.1.0/26link#6 UC 00 tap0 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is em endian-clean?
On 5/22/07, Jack Vogel <[EMAIL PROTECTED]> wrote: On 5/22/07, Jack Vogel <[EMAIL PROTECTED]> wrote: > Yes, Linux is tested on big endian, however FreeBSD testing > is limited. I would expect the shared code to be ok but the > core code is tested on little endian only. Do you have some > notion of where the problem is? I'm pretty busy with another > issue right at the moment. > > Jack I am setting up an older MAC our test group had, adding at least basic traffic passing test to our test cycle. Thank you. I appreciate this. -Kip ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000
The following reply was made to PR kern/112654; it has been noted by GNATS. From: Nagy Keve <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], Marius Strobl <[EMAIL PROTECTED]> Cc: Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 Date: Tue, 22 May 2007 19:39:03 +0200 > From: Marius Strobl <[EMAIL PROTECTED]> > Date: Wed, 16 May 2007 19:59:01 +0200 > I think this was fixed as part of src/sys/pci/if_pcn.c rev. > 1.81/1.69.2.7 > and src/sys/dev/mii/nsphy.c rev. 1.26/1.23.2.3. Could you please > give a > current FreeBSD-CURRENT or -STABLE a try? Suggested test was carried out on 22-MAY-2007. System source was synced to RELENG_6 via cvsup, and buildworld + buildkernel + installworld + installkernel was completed. The new 6.2-STABLE system generates the same kernel panic problem as described originally. Regards, Keve ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IP Checksum code from DragonFly BSD
Hello; Almost a year ago a port of DragonFly's BSD IP checksum code was made: http://lists.freebsd.org/pipermail/freebsd-current/2006-May/063286.html As part of the thread, Alexander Leidinger's experience while building the kernel with Intel's C was interesting: http://lists.freebsd.org/pipermail/freebsd-current/2006-May/063434.html My understanding is that if FreeBSD's IP checksumming code one day breaks or doesn't build with a new gcc we will need the patch there ... I hate it when working patches get lost in the mail archives! Perhaps someone with good net-fu would consider studying the patch and commit it, if adequate? cheers, Pedro. ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is em endian-clean?
On 5/22/07, Kip Macy <[EMAIL PROTECTED]> wrote: On 5/22/07, Jack Vogel <[EMAIL PROTECTED]> wrote: > On 5/22/07, Jack Vogel <[EMAIL PROTECTED]> wrote: > > Yes, Linux is tested on big endian, however FreeBSD testing > > is limited. I would expect the shared code to be ok but the > > core code is tested on little endian only. Do you have some > > notion of where the problem is? I'm pretty busy with another > > issue right at the moment. > > > > Jack > > I am setting up an older MAC our test group had, adding at least > basic traffic passing test to our test cycle. > Thank you. I appreciate this. Turns out they gave me a T2000 to use, just what everyone needs in their cubicle :) Now I just have to get it installed. Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is em endian-clean?
Turns out they gave me a T2000 to use, just what everyone needs in their cubicle :) Now I just have to get it installed. Jack Sigh, this just isnt my day, trying to boot the sparc64 april snapshot and the thing fails during boot, I wouldnt mind checking this endian issue if I could just get hardware that I can test on to work :) Any magic to get the box to boot? I am just using disk1, 'boot cdrom' from the prom, then hit enter to boot kernel it says: jumping to kernel entry at 0xc0068000. ERROR: Last Trap: Illegal Instruction. Suggestions? Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is em endian-clean?
Sun4v runs a hypervisor as part of its firmware. On freebsd it requires a different kernel from sparc64. Getting the same kernel to work on both would require more re-work of sparc64 than I felt like doing given that USIII isn't supported. There isn't currently an ISO image being produced. Cross-building and then netbooting from x86 is fairly painless. If that won't work for you I can figure out how to generate an ISO. -Kip On 5/22/07, Jack Vogel <[EMAIL PROTECTED]> wrote: > > Turns out they gave me a T2000 to use, just what everyone needs > in their cubicle :) Now I just have to get it installed. > > Jack > Sigh, this just isnt my day, trying to boot the sparc64 april snapshot and the thing fails during boot, I wouldnt mind checking this endian issue if I could just get hardware that I can test on to work :) Any magic to get the box to boot? I am just using disk1, 'boot cdrom' from the prom, then hit enter to boot kernel it says: jumping to kernel entry at 0xc0068000. ERROR: Last Trap: Illegal Instruction. Suggestions? Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Detecting LINK_UP / LINK_DOWN events
Finally got ifstated working the way I wanted. Thanks to Tom & Nikos.
The port included a man page for ifstated(8) - but was not sufficient
to get a newbie like me going. I found a good addition on openbsd
man pages ifstated.conf(5).
br,
==Sas3==
> -Original Message-
> > -Original Message-
> > From: Nikos Vassiliadis [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, May 22, 2007 2:58 PM
>
> > On Tuesday 22 May 2007 12:19, Sastry Tumuluri wrote:
> > > > -Original Message-
> > > > From: Tom Judge [mailto:[EMAIL PROTECTED]
> > > > Sent: Tuesday, May 22, 2007 12:01 AM
>
> > > > Sastry Tumuluri wrote:
> > > > > Friends,
> > > > >
> > > > > I am trying to catch and do some extra processing on
> > LINK_UP and
> > > > > LINK_DOWN events for my net interfaces (e.g., notify my
> > > >
> > > > admin, log the event, ...).
> > > >
> > > > > Tried this on both FreeBSD 6.1 and on FreeBSD 6.2.
> > > > >
> > > > > I tried using the devd.conf file with the following
> code (shows
> > > > > LINK_DOWN; wrote similar stuff for LINK_UP):
> > > > >
> > > > > notify 10 {
> > > > >match "type""LINK_DOWN";
> > > > >action "logger -s alert: Caught LINK_DOWN on dev:
> > $device-name
> > > > > subsys: $subsystem";
> > > > > };
> > > > >
> > > > > Didn't work. I tried the above with both strict match
> > conditions
> > > > > (using vendor, device and class matches) as well as very
> > > >
> > > > general (like the above).
> > > >
> > > > > Didn't work.
> > > > > I ran killed devd and ran it in the foreground with "devd
> > > >
> > > > -dD". Then I
> > > >
> > > > > logged into a different pty and used
> > > > > ifconfig lnc0 down #(lnc0 is my ethernet device).
> > > > > devd doesn't even seem to catch the event (no output at all
> > > >
> > > > - both on
> > > >
> > > > > screen and in syslog).
> > > > >
> > > > >
> > > > > On the other hand, "nomatch" and "attach" messages do
> > seem to get
> > > > > through (I wrote similar stuff for nomatch & attach,
> > and they are
> > > > > showing up at bootup and in syslog).
> > > > > What could I be doing wrong?
> > > >
> > > > Have you had a look at net/ifstated in ports?
> > > >
> > > > Tom
> > >
> > > Thanks, Tom! Though I had not heard of ifstated before
> > this, it looks
> > > interesting. I've managed to quickly get the latest port
> > and install
> > > it without any hassles - but am still a bit short on
> > documentation -
> > > esp., how the .conf file works, and how to make ifstated
> > work for me.
> > > I haven't used carp so far; and am not sure whether I need
> > to, if all
> > > I want is a simple "notification / logging". Any suggestions?
> > >
> > > On the other hand, I am still curious why devd didn't work in the
> > > first place. Is it a "futuristic" feature already
> > advertised (in the
> > > devd.conf file, there are examples of LINK_UP/LINK_DOWN
> > that make it
> > > look like it should work)? Or a case for better documentation?
> >
> > Did you try pulling the plug?
> > LINK events refer to the change of link status, not the "UP"
> > status. That is the "status: active" line .
> >
> > nik:0:~$ ifconfig fxp0
> > fxp0: flags=8843 mtu 1500
> > options=8
> > inet 192.168.1.71 netmask 0xff00 broadcast 192.168.1.255
> > ether 00:0c:f1:b9:38:50
> > media: Ethernet autoselect (100baseTX )
> > status: active
> >
> > HTH, Nikos
> >
>
> That solved one mystery, Nikos! Yes, the LINK_UP/LINK_DOWN do
> seem to refer to the status of the physical media (plugged in
> or out). While at it, I also found that
> ifconfig em0 down (not pulling out the media, just the command)
> does not send any status message (perhaps a driver
> feature? Not sure), but ifconfig em0 up
> does send a LINK_DOWN first and then a LINK_UP. This
> doesn't seem to
> have any relation to whether or not the IP address is
> there or -aliased.
>
> It still leaves me with my original problem that of
> "detecting changes to the interfaces and logging them /
> sending alerts". This needs to work for me for any
> Interface: real / psuedo (is that word for ppp0/tun0/etc...?)
> and any type of
> change: e.g. ip-addr change thru dhcp/pppoe/static etc.. :-(
> So I guess I'll keep plugging away at ifstated (carp or
> no-carp), then!! :-)
>
> Regards,
>
> ==Sas3==
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.467 / Virus Database: 269.7.6/814 - Release
> Date: 5/21/2007 2:01 PM
>
>
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.6/815 - Release Date: 5/22/2007
3:49 PM
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
A question about IPSec implementation..
Hi, all:
Recently I found a paragraph of codes about IPSec replay prevention
that confused me a lot. Could you shed some light on me?
line 2370 to line 2407 in ipsec.c deal with the replay window update.
/if (seq > replay->lastseq) {
/* seq is larger than lastseq. */
diff = seq - replay->lastseq;
/* new larger sequence number */
if (diff < wsizeb) {
/* In window */
/* set bit for this packet */
vshiftl(replay->bitmap, diff, replay->wsize);
replay->bitmap[frlast] |= 1;
} else {
/* this packet has a "way larger" */
bzero(replay->bitmap, replay->wsize);
replay->bitmap[frlast] = 1;
}
replay->lastseq = seq;
/* larger is good */
} else {
./
When the receiving sequence number larger than the maintained last
largest one, it will do /vshiftl/ and then /switch on the last bit of
the bitmap/. What I am wondering here is: is the current receiving
sequence number necessarily the last bit after doing /vshiftl/? Why to
do /vshiftl/?
Thanks for your time.
BR,
Yi-Wen
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
