bge & vlan stranges
Hello! I have Compaq DL360G2 with Broadcom BCM5701 Gigabit Ethernet and FreeBSD 5.1R installed. There are no problems if I use bge as usual network card, but when I try to use 802.1Q vlans, I can't receive (only receive, sending is ok) packets more then 1456 bytes! What is the problem? BGE driver, VLAN driver or my network configuration? Best wishes, Boris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bge & vlan stranges
Terry Lambert wrote: Hello! Boris Kovalenko wrote: I have Compaq DL360G2 with Broadcom BCM5701 Gigabit Ethernet and FreeBSD 5.1R installed. There are no problems if I use bge as usual network card, but when I try to use 802.1Q vlans, I can't receive (only receive, sending is ok) packets more then 1456 bytes! What is the problem? BGE driver, VLAN driver or my network configuration? The encapsulation information is subtracted from your available MTU, so that is correct. Some cards have a bogus feature that lets you send longer frames than the normal MTU, but you can't rely on this feature being interoperable between card vendors, or being supported on all cards. I suppose you want to do this because you are trunking a channel that goes to a border device, and for some reason you have disabled receipt of all ICMP, instead of only abusable ICMP, and thus you have broken end-to-end path MTU discovery. It would be best if you were to simply fix your ICMP. No, this is test machine, I have installed it two days ago and have firewall_type="OPEN" in my settings. So I have not disabled MTU path discovery You are speaking of. Nevertheless, what is "substracted from available MTU?" Why? The correct way it should work: 1500 bytes packet + 14 bytes ethernet header + 4 bytes CRC = 1518 bytes is standard ethernet frame and 1500 bytes packet + 14 bytes ethernet header + 4 bytes 802.1Q tag + 4 bytes CRC = 1522 bytes of standard 802.1Q encapsulated frame. All 802.1Q realizations I know working the same. -- Terry Boris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
arp: unknown hardware address format
Hello! What is the problem if I see arp: unknown hardware address format (0x4d6f) messages with bge driver on 5.1R? Yours truly, Boris Kovalenko ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ALTQ integration
Hello! May somebody tell me the status of ALTQ integration with FreeBSD? I need to know status for 5.x as well for 4.x too. Have read http://www.csl.sony.co.jp/person/kjc/kjc/software.html#ALTQ and misunderstood something. May somebody tell me in details what is the status of ALTQ implementation? Thanks in advance, Boris Kovalenko ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Can not remove directory
Hello! Can not remove directory /usr/obj/usr/src/gnu/usr.bin/cc/cc1 rm: /usr/obj/usr/src/gnu/usr.bin/cc/cc1: Directory not empty bash-2.05b# pwd; ls -la /usr/obj/usr/src/gnu/usr.bin/cc/cc1 total 4 drwxr-xr-x 2 root wheel 512 Oct 9 08:54 . drwxr-xr-x 13 root wheel 512 Oct 9 08:54 .. bash-2.05b# pwd; ls -la /usr/obj/usr/src/gnu/usr.bin/cc total 26 drwxr-xr-x 13 root wheel 512 Oct 9 08:54 . drwxr-xr-x 21 root wheel 512 Oct 9 11:23 .. drwxr-xr-x 2 root wheel 512 Oct 9 08:55 c++ drwxr-xr-x 2 root wheel 512 Oct 9 08:55 c++filt drwxr-xr-x 2 root wheel 512 Oct 9 08:54 cc1 drwxr-xr-x 2 root wheel 512 Oct 9 08:55 cc1obj drwxr-xr-x 2 root wheel 1024 Oct 9 08:55 cc1plus drwxr-xr-x 2 root wheel 512 Oct 9 08:55 cpp drwxr-xr-x 2 root wheel 512 Oct 9 08:55 cpp0 drwxr-xr-x 2 root wheel 512 Sep 26 10:34 doc drwxr-xr-x 2 root wheel 512 Oct 9 08:55 gcov drwxr-xr-x 2 root wheel 512 Oct 9 08:55 protoize drwxr-xr-x 2 root wheel 512 Oct 9 08:55 tradcpp0 What is wrong? Current system is 5.1-RELEASE-p8 Yours truly, Boris Kovalenko ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can not remove directory
Hello! I know about -r and -f options. They don't help. Proc wrote: man rm Note -r and -f. Boris Kovalenko wrote: Hello! Can not remove directory /usr/obj/usr/src/gnu/usr.bin/cc/cc1 rm: /usr/obj/usr/src/gnu/usr.bin/cc/cc1: Directory not empty bash-2.05b# pwd; ls -la /usr/obj/usr/src/gnu/usr.bin/cc/cc1 total 4 drwxr-xr-x 2 root wheel 512 Oct 9 08:54 . drwxr-xr-x 13 root wheel 512 Oct 9 08:54 .. bash-2.05b# pwd; ls -la /usr/obj/usr/src/gnu/usr.bin/cc total 26 drwxr-xr-x 13 root wheel 512 Oct 9 08:54 . drwxr-xr-x 21 root wheel 512 Oct 9 11:23 .. drwxr-xr-x 2 root wheel 512 Oct 9 08:55 c++ drwxr-xr-x 2 root wheel 512 Oct 9 08:55 c++filt drwxr-xr-x 2 root wheel 512 Oct 9 08:54 cc1 drwxr-xr-x 2 root wheel 512 Oct 9 08:55 cc1obj drwxr-xr-x 2 root wheel 1024 Oct 9 08:55 cc1plus drwxr-xr-x 2 root wheel 512 Oct 9 08:55 cpp drwxr-xr-x 2 root wheel 512 Oct 9 08:55 cpp0 drwxr-xr-x 2 root wheel 512 Sep 26 10:34 doc drwxr-xr-x 2 root wheel 512 Oct 9 08:55 gcov drwxr-xr-x 2 root wheel 512 Oct 9 08:55 protoize drwxr-xr-x 2 root wheel 512 Oct 9 08:55 tradcpp0 What is wrong? Current system is 5.1-RELEASE-p8 Yours truly, Boris Kovalenko ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can not remove directory
Hello! Seems You are right: BAD INODE NUMBER FOR '.' I=353381 OWNER=root MODE=40755 SIZE=512 MTIME=Oct 9 08:54 2003 DIR=/obj/usr/src/gnu/usr.bin/cc/cc1 UNEXPECTED SOFT UPDATE INCONSISTENCY FIX? no Will reboot and run fsck manually. Thanks for advance! Yours truly, Boris Kovalenko Dan Nelson wrote: In the last episode (Oct 09), Boris Kovalenko said: Can not remove directory /usr/obj/usr/src/gnu/usr.bin/cc/cc1 rm: /usr/obj/usr/src/gnu/usr.bin/cc/cc1: Directory not empty bash-2.05b# pwd; ls -la /usr/obj/usr/src/gnu/usr.bin/cc/cc1 total 4 drwxr-xr-x 2 root wheel 512 Oct 9 08:54 . drwxr-xr-x 13 root wheel 512 Oct 9 08:54 .. Interesting. Usually you get this after a crash, due to how softupdates buffers directory updates. The background fsck should have repaired the directory, though. If it isn't still running, try rebooting in single-user mode and run fsck -p on the filesystem. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
Hello! Yes, unsigned, so we have 4G limit, which may simple be overflowed by (for example) PPPoE connection. Yes, RADIUS standard defines new attributes for big words, but current PPP does not supports it (it, so our knowledge about RFC is useless :) Again, rad_put_int defined u_int32_t parameter, so if a have dowloaded 4.5G (for example) what number will send to radius? Regards, Boris Barney Wolff wrote: On Wed, Nov 19, 2003 at 09:00:01AM +0500, Boris Kovalenko wrote: I found a serious bug in RADIUS accounting code. The problem is that OctetsIn and OctetsOut are defined as unsingned long long, but the RADIUS supports only INT32 values, so, when we're doing rad_put_int(r->cx.rad, RAD_ACCT_OUTPUT_OCTETS, stats->OctetsOut) in radius.c for OctetsOut (and OctetsIn also) we loosing information if OctetsOut is greater then INT32_MAX. This should be fixed. Note that RADIUS integers are unsigned, so the limit is 2^32-1. Also, RFC2869 defines attributes to hold the high-order parts. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
Hello! Standard PPP does not support UPDATE packets, and of course (as my RADIUS knowledge) the counters should not be resetted, because RADIUS updates the same record. Regards, Boris Michael Bretterklieber wrote: Hi, On Wed, 19 Nov 2003, Boris Kovalenko wrote: Hello! Yes, unsigned, so we have 4G limit, which may simple be overflowed by (for example) PPPoE connection. Yes, RADIUS standard defines new attributes for big words, but current PPP does not supports it (it, so our knowledge about RFC is useless :) Again, rad_put_int defined u_int32_t parameter, so if a have dowloaded 4.5G (for example) what number will send to radius? How about sending periodic RADIUS accounting updates? After each accounting update the counters could be reset, but I'm not sure whether this is RFC compliant, i.e. whether allways the complete value has to be send or whether the counters could be reset, after each update. For Mpd we implemented it without resetting the counters, but maybe that's not 100% right. bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 --- -- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
The RFC says: 5.4. Acct-Output-Octets blabla can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. It looks like, that these counters must not present in accounting updates. You are right, but your words - "but a patch could be written :-)". Again, I'm talking not about UPDATE packets and presence of any attributes in RADIUS requests. I'm talking about wrong handling of Acct-Input-Octets & Acct-Output-Octets with current PPP RADIUS implementation. How this will be done, by implementing RFC2869 support or just by resending STOP request N times is not so important, but somehow this should be done. I may try to write patch myself, but I'm looking for someone who supervises my patch and commit it if no problems will be founded. Regards, Boris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
Hello! So sending interim update packets won't help. Like I said :) looking for someone who supervises my patch and commit it if no problems will be founded. this can be a problem :-) This is the problem now :) I'm wondering if I only one useing ppp with RADIUS accounting with FreeBSD. Regards, Boris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ppp RADIUS accounting bug
Hello! I found a serious bug in RADIUS accounting code. The problem is that OctetsIn and OctetsOut are defined as unsingned long long, but the RADIUS supports only INT32 values, so, when we're doing rad_put_int(r->cx.rad, RAD_ACCT_OUTPUT_OCTETS, stats->OctetsOut) in radius.c for OctetsOut (and OctetsIn also) we loosing information if OctetsOut is greater then INT32_MAX. This should be fixed. Regards, Boris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
