Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 48 replies
  • Subscribers 2 subscribers
  • Views 9089 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

5.027 Kernel Upgrade...!

Bryan_01
Anyone tried this update yet. I'm too scared to do it after having to reboot after the last couple of updates - will this one requre a power cycle or maybe it can only be done in the dark!

Seriously, let me know your experiences. I am most worried about the new network card drivers for e100 cards which I use.

Thanks
Bryan


This thread was automatically locked due to age.
  • 0 in reply to ReD-MaN
    This is adversely affecting me. Is there a way to rollback to 5.026 (without having to re-install)?

    Thanks,
    Barry
  • 0 in reply to BarryG
    [ QUOTE ]
    This is adversely affecting me. Is there a way to rollback to 5.026 (without having to re-install)?

    Thanks,
    Barry 

    [/ QUOTE ]
    Hi Barry,
    do you have a web-page that you can post here where the problem occurs?
    (I do not have an idea to switch back to 5.026 without doing a reinstall)

    cu SveN
  • 0 in reply to SveN_01
    Can you check whether you have enabled one of the following options in "Packet Filter->Advanced":
    - "Strict TCP Session Handling"
    - "Validate Packet-Length"

    Regards,
    Stephan
  • 0 in reply to Stephan_Scholz
    Hi Stephan, 

    both Options were OFF (I turned them on for a test, but that didn't help). 
    SYN Rate Limiter was ON (I turned this one OFF, this didn't help also).

    I kernel.log still the same: 
     2004:11:18-14:45:52 (none) kernel: ip_conntrack_tcp: INVALID: invalid state SRC= DST= LEN=48 TOS=0x00 PREC=0x00 TTL=114 ID=47890 DF PROTO=TCP SPT=443 DPT=2676 SEQ=2878483313 ACK=1416483982 WINDOW=65535 RES=0x00 ACK URGP=0
  • 0 in reply to Stephan_Scholz
    I had the Strict TCP option enabled, wasn't aware it was. Disabled it now, will see how things are now.
  • 0 in reply to ReD-MaN
    Still having invalid state, and invalid syn showing up.
  • 0 in reply to ReD-MaN
    Here are the ones I am seeing, sanitized:

    2004:11:18-08:51:54 (none) kernel: ip_conntrack_tcp: INVALID: invalid state SRC=192.168.X.X DST=X.X.X.X LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=36805 DF PROTO=TCP SPT=2180 DPT=4806 SEQ=512916997 ACK=3438793701 WINDOW=64512 RES=0x00 ACK URGP=0 

    2004:11:18-08:52:41 (none) kernel: ip_conntrack_tcp: INVALID: invalid SYN (ignored) SRC=X.X.X.X DST=X.X.X.X LEN=48 TOS=0x00 PREC=0x00 TTL=43 ID=38242 DF PROTO=TCP SPT=4616 DPT=2180 SEQ=1266878367 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405AC01010402) 

    2004:11:18-08:52:41 (none) kernel: ip_conntrack_tcp: INVALID: invalid state SRC=192.168.X.X DST=X.X.X.X LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=38045 DF PROTO=TCP SPT=2180 DPT=4616 SEQ=525803101 ACK=1266878368 WINDOW=64512 RES=0x00 ACK URGP=0
  • 0 in reply to ReD-MaN
    And now, after looking through my logs, I am seeing this one as well:

    2004:11:18-08:27:23 (none) kernel: ip_conntrack_tcp: IGNORED: Out of window data; SEQ is over the upper bound (over the window of the receiver)

    AND, also a LOT more of the bad tcp checksum errors with none of the advanced PF options enabled.
  • 0 in reply to ReD-MaN
    Interesting..i am not having this issue..but i will definitly keep a lookout for others that maybe..

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • 0 in reply to SveN_01
    Last night, I was unable to access https://wwws.ameritrade.com/apps/LogIn/
    from one PC while another PC was running P2P (eMule) at 100kbits/sec. (my outgoing bw is 256kbits (measured))

    browser reported connection resets and other errors.

    normal HTTP was working fine.

    further throttling the P2P reduced the errors.

    BTW, I'm not using ASL's proxy, but am using another Squid proxy in the DMZ.

    This did not occur prior to 5.027.
    Also, I believe general connectivity has gone downhill in 5.027.
    Even with QOS set up properly, surfing is unbearably slow while P2P is running, even at only 50kbits/sec.

    Barry
Cookie Information Banner